Комментарии 41
Лично мне очень помог интерактивный туториал Rust by Example. Однако, стоит отметить, что этот туториал не для новичков в программировании, а для тех, кто уже хорошо владеет другими языками. Всё-таки, мало языков программирования, с которыми можно ознакомить в рамках одной статьи, вот, например, этот туториал по Rust включает в себя 20 глав. Тем не менее, я думаю, ваша статья тоже будет полезна многим.
+3
Ваш комментарий и статья автора заинтересовали меня и подтолкнули поближе познакомиться с Rust. Спасибо большое)
+3
Лично мне очень помог интерактивный туториал Rust by Example.
Поддержу — написано весьма неплохо, жаль на русский перевода нет (или я что-то упустил?).
Правда я читал параллельно с официальной книгой — временами так проще разобраться. Тем более, что для неё и перевод имеется.
+1
Мне в этой статье только немного странно, зачем на примере строк это показывать, раз до
&str
дело не доходит и он даже не упоминается. И тут никак не объясняется, почему в одном месте (println!
) мы используем просто строковый литерал, а в других местах мы делаем String::from
. Лучше было бы тогда, как мне кажется, завести структуру с каким-нибудь u8
полем и ее мучать, а то String/&str
— это известное больное место для знакомящихся с языком.+1
Про
&String
в clippy даже предупреждение есть: https://github.com/Manishearth/rust-clippy/wiki#ptr_arg+1
Могу только предположить, что автор не стал заморачиваться. Вероятно, для структуры сложнее было бы придумать условно полезную функцию. (:
Опять же, кто-нибудь мог бы придраться: мол такую мелкую структуру можно и копированием передавать.
Опять же, кто-нибудь мог бы придраться: мол такую мелкую структуру можно и копированием передавать.
+1
Очень интересный язык, но синтаксис удручает, лучше пошли бы по пути D или C#.
-2
Мне кажется, вся статья как раз и намекает, почему синтаксически ржавчина идет не по "пути D или C#". У языков приоритеты сильно отличаются.
+7
Давайте разберём на примерах? (:
Потому что, например, сопоставление с образцом мне в Rust нравится больше. Хотя не буду спорить с тем, что у последнего синтаксис в общем-то более «замусоренный». Вот только это вынужденное решение. Скажем, много визуального шума привносит указание лайфтаймов, но ни в C# ни в D их просто нет. Аналогично с макросами, хотя мне и кажется, что они могли бы быть красивее, но уж лучше так, чем никак.
Потому что, например, сопоставление с образцом мне в Rust нравится больше. Хотя не буду спорить с тем, что у последнего синтаксис в общем-то более «замусоренный». Вот только это вынужденное решение. Скажем, много визуального шума привносит указание лайфтаймов, но ни в C# ни в D их просто нет. Аналогично с макросами, хотя мне и кажется, что они могли бы быть красивее, но уж лучше так, чем никак.
+2
Я тоже согласен с автором оригинального комментария, даже вот смотря на код приведенный в статье, и не углубляясь в дебри языка, поскольку его я пока не знаю:
String::from — почему не точка, ведь это 2 символа против одного;
fn same_length(s1: &String, s2: &String) -> bool — тут очень похоже на делфи, кроме "->", но все равно даже объявление функции выглядит, как вы уже сказали, несколько «замусоренным»
Хотя это мелочи и, возможно, действительно будет выглядеть оправданно при более детальном изучении
String::from — почему не точка, ведь это 2 символа против одного;
fn same_length(s1: &String, s2: &String) -> bool — тут очень похоже на делфи, кроме "->", но все равно даже объявление функции выглядит, как вы уже сказали, несколько «замусоренным»
Хотя это мелочи и, возможно, действительно будет выглядеть оправданно при более детальном изучении
-1
почему не точка, ведь это 2 символа против одного;
Чтобы разделить доступ к объекту и чему-то внутри "области видимости". Можно спорить о пользе такого разделения, но мне как С++ программисту вполне привычно.
но все равно даже объявление функции выглядит, как вы уже сказали, «замусоренным»
А вот тут не соглашусь. Покажите "исправленный" вариант, потому что я не вижу что тут особо сделать можно не потеряв в чём-то другом.
Скажем, мы можем убрать амперсанды, если введём семантику передачи по ссылке, но это плохо живёт без GC и противоречит тому, что Rust пытается добиться. Ну или указание типа — можно сделать это перед именем переменной, как в куче других языков, но в Rust такой синтаксис работает везде и это хорошо для единообразия. То есть, мы или получим кучу разных правил для отдельных случаев или "мусор" просто перенесётся из этого места в, скажем, сопоставление с образцом.
Разве что от ключевого слова "fn" можно избавиться, но и тут не всё так просто. А уж такое указание возвращаемого типа есть и в С++ и выглядит оно менее изящно из-за необходимости писать
auto
перед именем функции.+5
А что скажете про двоеточие после имени входного параметра?
0
Упрощает грамматику языка, убирает неоднозначности. Слоты аргументов в сигнатуре создают контекст сопоставления (аналогично с
Так что можно писать, если вдруг надо, всякое странное:
https://play.rust-lang.org/?gist=dc15c72441ad9d9371f68080790637e5
Ну и не так мало людей считают, что так читаемость улучшается, но это уже вкусовщина.
let
), так что не надо вводить лишнюю сущность в грамматику.Так что можно писать, если вдруг надо, всякое странное:
struct S { a: u8, b: u8, c: u8 }
fn f(S{c, ..}: S) {
println!("c={}", c);
}
https://play.rust-lang.org/?gist=dc15c72441ad9d9371f68080790637e5
Ну и не так мало людей считают, что так читаемость улучшается, но это уже вкусовщина.
+4
Как по мне, двоеточие визуально отделяет имя параметра от его типа, что есть хорошо. Если вы ссылаетесь на golang, то там для такого различения требуется немного «приморгаться».
+3
Опять же, единообразие:
Обойтись без let не получится: всё равно придётся вводить что-то типа плюсового
Но как быть с остальными? Опять же,
let a = 10i32;
let b: i32 = 10;
let (c, d) = (10, 20);
let (e, f): (i32, i32) = (10, 20);
Обойтись без let не получится: всё равно придётся вводить что-то типа плюсового
auto
. Первые два случая выглядят более-менее нормально:auto a = 10;
int b = 10;
Но как быть с остальными? Опять же,
let
вполне естественно используется в конструкции if let
. Не уверен, что придать такой же смысл auto удалось бы. В итоге придётся вводить дополнительный синтаксис.+4
> А что скажете про двоеточие после имени входного параметра?
Аболютно стандартная нотация, общепринятая в литературе по computer science, языкам программирования, теории типов; используется во многих современных ЯП. Это *не* «как в Дельфи/Паскале», это «как везде кроме Си-подобных языков».
Аболютно стандартная нотация, общепринятая в литературе по computer science, языкам программирования, теории типов; используется во многих современных ЯП. Это *не* «как в Дельфи/Паскале», это «как везде кроме Си-подобных языков».
+5
НЛО прилетело и опубликовало эту надпись здесь
Все больше смотрю в сторону этого языка. Интересно насколько возможно полуавтоматическое портирование с java, или C. Для высоканагруженых веб систем, было бы идеальное решение. Быстро, безопасно.
+1
Интересно насколько возможно полуавтоматическое портирование с java, или C.
В идиоматичный код, наверное, не возможно. Все-таки система владения/одалживания требует специфической структуризации кода.
+2
> Интересно насколько возможно полуавтоматическое портирование с java, или C.
Насчёт джавы точно сомневаюсь, да и с С, подозреваю, будут проблемы. Всё-таки язык «заставляет» писать несколько по другому.
С другой стороны, если ничего не путают, то RustType изначально как раз прямо портировали с stb_truetype. Правда вручную. К сожалению, не знаю насколько процесс был трудоёмким.
Насчёт джавы точно сомневаюсь, да и с С, подозреваю, будут проблемы. Всё-таки язык «заставляет» писать несколько по другому.
С другой стороны, если ничего не путают, то RustType изначально как раз прямо портировали с stb_truetype. Правда вручную. К сожалению, не знаю насколько процесс был трудоёмким.
0
про джаву, я не добписал коментарий. Насколько я знаю в rust будет добавляться garbage collector, таким образом портирование уже не будет таким уж сложным.
0
> таким образом портирование уже не будет таким уж сложным.
Вероятно, да. Вот только если использовать его для всего, то вряд ли что-то выиграем. Всё-таки в джаве GC развивают и уделяют этому немало внимания, а в Rust — это просто решение отдельной проблемы, а не ключевая особенность языка. Да и ресурсы разработчиков этих языков не сопоставимы.
Вероятно, да. Вот только если использовать его для всего, то вряд ли что-то выиграем. Всё-таки в джаве GC развивают и уделяют этому немало внимания, а в Rust — это просто решение отдельной проблемы, а не ключевая особенность языка. Да и ресурсы разработчиков этих языков не сопоставимы.
0
> Насколько я знаю в rust будет добавляться garbage collector
Меня эта перспектива очень смущает до сих пор, все надеюсь что откажутся. Не верю я, что на такой стадии получится гладко в язык вписать GC (статьи про текущий попытки это сделать лично мне ужасают количеством тонкостей) и сильно побаиваюсь разделения crates.io на два лагеря и вытекающие из этого сложности.
Меня эта перспектива очень смущает до сих пор, все надеюсь что откажутся. Не верю я, что на такой стадии получится гладко в язык вписать GC (статьи про текущий попытки это сделать лично мне ужасают количеством тонкостей) и сильно побаиваюсь разделения crates.io на два лагеря и вытекающие из этого сложности.
+1
вообще с одной стороны GC нужен, тк есть огромный клас задач не требовательных к ресурсам. Да и некоторые алгоритмы значительно легчи написать с GC. В тоже время я разделяю ваши опасения, нужно его добавить так, чтобы он был лаконичен в языке и не подразумевал его повсеменое использоване.
-1
Насколько я помню GC ставится как отдельный модуль, и никто не мешает им не пользоваться, если не нужно. Но сама возможность его наличия — почему бы и нет? У GC хватает преимуществ вроде удобного менеджера памяти. Платить нужно за это только на этапе сборки, но иногда плюсы покрывают минусы.
0
RustType, как я понимаю, написан с нуля на ржавчине, просто с сильным поглядыванием на структуры и алгоритмы stb_truetype. А потом проект несколько в сторону уходит и своих фишек уже добавляет.
А вот github.com/PistonDevelopers/truetype — это именно порт stb_truetype. У них там, особенно если в историю залезть, вообще все в unsafe и сырых указателях, которые они мееедленно вычищают. И до сих пор не вычистили. Так что портирование подобного сишного кода выглядит довольно трудоемко.
А вот github.com/PistonDevelopers/truetype — это именно порт stb_truetype. У них там, особенно если в историю залезть, вообще все в unsafe и сырых указателях, которые они мееедленно вычищают. И до сих пор не вычистили. Так что портирование подобного сишного кода выглядит довольно трудоемко.
+1
>Вы можете одалживать данные любое количество раз, но не можете их менять.
Через Mutex можно. Скорее так: если вы все делаете правильно, раст гарантирует что в любой момент времени у вас только один владелец который может менять данные.
Через Mutex можно. Скорее так: если вы все делаете правильно, раст гарантирует что в любой момент времени у вас только один владелец который может менять данные.
+1
Через
Cell
или RefCell
скорее. Но, в любом случае, в статье же о работе по умолчанию говорится.+1
Скорее так: если вы все делаете правильно, раст гарантирует что в любой момент времени у вас только один владелец который может менять данные.
С поправкой соглашусь, потому что если очень захотеть, то "можно" и через transmute. (:
Я так понимаю, автор не хотел сразу вываливать на читателя все нюансы. Всё-таки статья для новичков.
0
Вот тут хорошее описание правил заимствования, там же есть про владение и время жизни:
rurust.github.io/rust_book_ru/src/references-and-borrowing.html
И вообще, хорошая книга для старта изучения Rust :)
rurust.github.io/rust_book_ru/src/references-and-borrowing.html
И вообще, хорошая книга для старта изучения Rust :)
0
Это вообще самая главная документация по ржавчине, с ней стоит в любом случае ознакомиться всем интересующимся. Но там как раз во многих местах нет объяснения почему в языке сделано именно так как сделано. Если и есть, то очень краткое. Для полноценного выяснения причин часто приходится спрашивать в чатах-форумах всяких или заниматься RFC-археологией (там есть клевые секции с альтернативами), а вот есть мнение, что хорошее понимание причин позволяет лучше понимать и конечный результат.
Хотя конкретно в этой главе, которую, если не ошибаюсь, уже кучу раз переписывали, мотивация не так плохо показана.
Хотя конкретно в этой главе, которую, если не ошибаюсь, уже кучу раз переписывали, мотивация не так плохо показана.
+2
а вот есть мнение, что хорошее понимание причин позволяет лучше понимать и конечный результат.
Могу сказать, что прочувствовал это на себе. Вроде, кругозор не такой уж узкий — лиспом интересовался, про хаскель пару книг прочёл. Самое забавное, когда язык выглядит "совсем по другому", то и воспринимать его легче — нет такого, что каждая мелочь кажется непривычной (это делает язык целиком).
А вот в расте постоянно возникало раздражение и вопросы "почему они сделали так?!!", но после более глубокого изучения вопроса, почти всегда приходит понимание и решение кажется правильным.
Конечно, мне далеко не всё в языке нравится, но эти решения, по крайней мере, выглядят последовательными.
+2
Мне одному кажется, что автор оригинала статьи просто увидел новый язык, прочитал 2-3 главы и сразу написал статью? 0_о
+1
У него в блоге имеются другие, более старые, статьи про раст, так что сомневаюсь.
0
Значит ощущения подвели. Просто на мой взгляд, немного странно на примере Hello World разбирать особенности языка и его философию.
0
Просто на мой взгляд, немного странно на примере Hello World разбирать особенности языка и его философию.
Если попытаться объяснить всё сразу, то у нас получится аналог официальной документации. Данная статья — (насколько я понимаю) про другое. Многие ведь действительно не идут дальше поверхностных оценок типа "фуу дурацкие let, почему не сделали как в С++". Автор же, как мне кажется, смог донести кое-какие принципы языка даже до тех, кто его впервые увидел. Пусть и на несколько дурацких примерах.
+4
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Rust через его основополагающие принципы