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