Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 41

Лично мне очень помог интерактивный туториал Rust by Example. Однако, стоит отметить, что этот туториал не для новичков в программировании, а для тех, кто уже хорошо владеет другими языками. Всё-таки, мало языков программирования, с которыми можно ознакомить в рамках одной статьи, вот, например, этот туториал по Rust включает в себя 20 глав. Тем не менее, я думаю, ваша статья тоже будет полезна многим.
Всего голосов 5: ↑4 и ↓1+3
Ваш комментарий и статья автора заинтересовали меня и подтолкнули поближе познакомиться с Rust. Спасибо большое)
Всего голосов 3: ↑3 и ↓0+3
Лично мне очень помог интерактивный туториал Rust by Example.

Поддержу — написано весьма неплохо, жаль на русский перевода нет (или я что-то упустил?).

Правда я читал параллельно с официальной книгой — временами так проще разобраться. Тем более, что для неё и перевод имеется.
Всего голосов 1: ↑1 и ↓0+1
Есть перевод, но я не знаю насколько он полон и актуален
Всего голосов 2: ↑2 и ↓0+2
Мне в этой статье только немного странно, зачем на примере строк это показывать, раз до &str дело не доходит и он даже не упоминается. И тут никак не объясняется, почему в одном месте (println!) мы используем просто строковый литерал, а в других местах мы делаем String::from. Лучше было бы тогда, как мне кажется, завести структуру с каким-нибудь u8 полем и ее мучать, а то String/&str — это известное больное место для знакомящихся с языком.
Всего голосов 1: ↑1 и ↓0+1
Могу только предположить, что автор не стал заморачиваться. Вероятно, для структуры сложнее было бы придумать условно полезную функцию. (:

Опять же, кто-нибудь мог бы придраться: мол такую мелкую структуру можно и копированием передавать.
Всего голосов 1: ↑1 и ↓0+1
Очень интересный язык, но синтаксис удручает, лучше пошли бы по пути D или C#.
Всего голосов 6: ↑2 и ↓4-2
Мне кажется, вся статья как раз и намекает, почему синтаксически ржавчина идет не по "пути D или C#". У языков приоритеты сильно отличаются.
Всего голосов 7: ↑7 и ↓0+7
Давайте разберём на примерах? (:

Потому что, например, сопоставление с образцом мне в Rust нравится больше. Хотя не буду спорить с тем, что у последнего синтаксис в общем-то более «замусоренный». Вот только это вынужденное решение. Скажем, много визуального шума привносит указание лайфтаймов, но ни в C# ни в D их просто нет. Аналогично с макросами, хотя мне и кажется, что они могли бы быть красивее, но уж лучше так, чем никак.
Всего голосов 2: ↑2 и ↓0+2
Я тоже согласен с автором оригинального комментария, даже вот смотря на код приведенный в статье, и не углубляясь в дебри языка, поскольку его я пока не знаю:
String::from — почему не точка, ведь это 2 символа против одного;
fn same_length(s1: &String, s2: &String) -> bool — тут очень похоже на делфи, кроме "->", но все равно даже объявление функции выглядит, как вы уже сказали, несколько «замусоренным»
Хотя это мелочи и, возможно, действительно будет выглядеть оправданно при более детальном изучении
Всего голосов 1: ↑0 и ↓1-1
почему не точка, ведь это 2 символа против одного;

Чтобы разделить доступ к объекту и чему-то внутри "области видимости". Можно спорить о пользе такого разделения, но мне как С++ программисту вполне привычно.
но все равно даже объявление функции выглядит, как вы уже сказали, «замусоренным»

А вот тут не соглашусь. Покажите "исправленный" вариант, потому что я не вижу что тут особо сделать можно не потеряв в чём-то другом.

Скажем, мы можем убрать амперсанды, если введём семантику передачи по ссылке, но это плохо живёт без GC и противоречит тому, что Rust пытается добиться. Ну или указание типа — можно сделать это перед именем переменной, как в куче других языков, но в Rust такой синтаксис работает везде и это хорошо для единообразия. То есть, мы или получим кучу разных правил для отдельных случаев или "мусор" просто перенесётся из этого места в, скажем, сопоставление с образцом.

Разве что от ключевого слова "fn" можно избавиться, но и тут не всё так просто. А уж такое указание возвращаемого типа есть и в С++ и выглядит оно менее изящно из-за необходимости писать auto перед именем функции.
Всего голосов 5: ↑5 и ↓0+5
А что скажете про двоеточие после имени входного параметра?
Комментарий пока не оценивали0
Упрощает грамматику языка, убирает неоднозначности. Слоты аргументов в сигнатуре создают контекст сопоставления (аналогично с 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: ↑4 и ↓0+4
Как по мне, двоеточие визуально отделяет имя параметра от его типа, что есть хорошо. Если вы ссылаетесь на golang, то там для такого различения требуется немного «приморгаться».
Всего голосов 3: ↑3 и ↓0+3
Опять же, единообразие:
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: ↑4 и ↓0+4
> А что скажете про двоеточие после имени входного параметра?

Аболютно стандартная нотация, общепринятая в литературе по computer science, языкам программирования, теории типов; используется во многих современных ЯП. Это *не* «как в Дельфи/Паскале», это «как везде кроме Си-подобных языков».
Всего голосов 5: ↑5 и ↓0+5
НЛО прилетело и опубликовало эту надпись здесь
Все больше смотрю в сторону этого языка. Интересно насколько возможно полуавтоматическое портирование с java, или C. Для высоканагруженых веб систем, было бы идеальное решение. Быстро, безопасно.
Всего голосов 1: ↑1 и ↓0+1
Интересно насколько возможно полуавтоматическое портирование с java, или C.

В идиоматичный код, наверное, не возможно. Все-таки система владения/одалживания требует специфической структуризации кода.
Всего голосов 2: ↑2 и ↓0+2
> Интересно насколько возможно полуавтоматическое портирование с java, или C.

Насчёт джавы точно сомневаюсь, да и с С, подозреваю, будут проблемы. Всё-таки язык «заставляет» писать несколько по другому.

С другой стороны, если ничего не путают, то RustType изначально как раз прямо портировали с stb_truetype. Правда вручную. К сожалению, не знаю насколько процесс был трудоёмким.
Комментарий пока не оценивали0
про джаву, я не добписал коментарий. Насколько я знаю в rust будет добавляться garbage collector, таким образом портирование уже не будет таким уж сложным.
Комментарий пока не оценивали0
> таким образом портирование уже не будет таким уж сложным.

Вероятно, да. Вот только если использовать его для всего, то вряд ли что-то выиграем. Всё-таки в джаве GC развивают и уделяют этому немало внимания, а в Rust — это просто решение отдельной проблемы, а не ключевая особенность языка. Да и ресурсы разработчиков этих языков не сопоставимы.
Комментарий пока не оценивали0
> Насколько я знаю в rust будет добавляться garbage collector

Меня эта перспектива очень смущает до сих пор, все надеюсь что откажутся. Не верю я, что на такой стадии получится гладко в язык вписать GC (статьи про текущий попытки это сделать лично мне ужасают количеством тонкостей) и сильно побаиваюсь разделения crates.io на два лагеря и вытекающие из этого сложности.
Всего голосов 1: ↑1 и ↓0+1
вообще с одной стороны GC нужен, тк есть огромный клас задач не требовательных к ресурсам. Да и некоторые алгоритмы значительно легчи написать с GC. В тоже время я разделяю ваши опасения, нужно его добавить так, чтобы он был лаконичен в языке и не подразумевал его повсеменое использоване.
Всего голосов 3: ↑1 и ↓2-1
вообще с одной стороны GC нужен, тк есть огромный клас задач не требовательных к ресурсам. Да и некоторые алгоритмы значительно легчи написать с GC.

Как по мне, если для удобного решения задачи Rc не хватает, то лучше такое на другом языке это дело и написать.
Всего голосов 1: ↑1 и ↓0+1
Насколько я помню GC ставится как отдельный модуль, и никто не мешает им не пользоваться, если не нужно. Но сама возможность его наличия — почему бы и нет? У GC хватает преимуществ вроде удобного менеджера памяти. Платить нужно за это только на этапе сборки, но иногда плюсы покрывают минусы.
Комментарий пока не оценивали0
например при создании gui, объектов мало, зависимости простые, ручное управление памятью просто напросто излишни
Комментарий пока не оценивали0
RustType, как я понимаю, написан с нуля на ржавчине, просто с сильным поглядыванием на структуры и алгоритмы stb_truetype. А потом проект несколько в сторону уходит и своих фишек уже добавляет.

А вот github.com/PistonDevelopers/truetype — это именно порт stb_truetype. У них там, особенно если в историю залезть, вообще все в unsafe и сырых указателях, которые они мееедленно вычищают. И до сих пор не вычистили. Так что портирование подобного сишного кода выглядит довольно трудоемко.
Всего голосов 1: ↑1 и ↓0+1
А вот github.com/PistonDevelopers/truetype — это именно порт stb_truetype.

Перепутал всё-таки значит: из-за очень похожих названий сложно нагуглить. Помню читал какой-то "промежуточный отчёт" о портировании и тоже показалось, что это не такое и простое дело.
Комментарий пока не оценивали0
>Вы можете одалживать данные любое количество раз, но не можете их менять.
Через Mutex можно. Скорее так: если вы все делаете правильно, раст гарантирует что в любой момент времени у вас только один владелец который может менять данные.
Всего голосов 1: ↑1 и ↓0+1
Через Cell или RefCell скорее. Но, в любом случае, в статье же о работе по умолчанию говорится.
Всего голосов 1: ↑1 и ↓0+1
Скорее так: если вы все делаете правильно, раст гарантирует что в любой момент времени у вас только один владелец который может менять данные.

С поправкой соглашусь, потому что если очень захотеть, то "можно" и через transmute. (:
Я так понимаю, автор не хотел сразу вываливать на читателя все нюансы. Всё-таки статья для новичков.
Комментарий пока не оценивали0
Это вообще самая главная документация по ржавчине, с ней стоит в любом случае ознакомиться всем интересующимся. Но там как раз во многих местах нет объяснения почему в языке сделано именно так как сделано. Если и есть, то очень краткое. Для полноценного выяснения причин часто приходится спрашивать в чатах-форумах всяких или заниматься RFC-археологией (там есть клевые секции с альтернативами), а вот есть мнение, что хорошее понимание причин позволяет лучше понимать и конечный результат.

Хотя конкретно в этой главе, которую, если не ошибаюсь, уже кучу раз переписывали, мотивация не так плохо показана.
Всего голосов 2: ↑2 и ↓0+2
а вот есть мнение, что хорошее понимание причин позволяет лучше понимать и конечный результат.

Могу сказать, что прочувствовал это на себе. Вроде, кругозор не такой уж узкий — лиспом интересовался, про хаскель пару книг прочёл. Самое забавное, когда язык выглядит "совсем по другому", то и воспринимать его легче — нет такого, что каждая мелочь кажется непривычной (это делает язык целиком).

А вот в расте постоянно возникало раздражение и вопросы "почему они сделали так?!!", но после более глубокого изучения вопроса, почти всегда приходит понимание и решение кажется правильным.

Конечно, мне далеко не всё в языке нравится, но эти решения, по крайней мере, выглядят последовательными.
Всего голосов 2: ↑2 и ↓0+2
Мне одному кажется, что автор оригинала статьи просто увидел новый язык, прочитал 2-3 главы и сразу написал статью? 0_о
Всего голосов 1: ↑1 и ↓0+1
У него в блоге имеются другие, более старые, статьи про раст, так что сомневаюсь.
Комментарий пока не оценивали0
Значит ощущения подвели. Просто на мой взгляд, немного странно на примере Hello World разбирать особенности языка и его философию.
Комментарий пока не оценивали0
Просто на мой взгляд, немного странно на примере Hello World разбирать особенности языка и его философию.

Если попытаться объяснить всё сразу, то у нас получится аналог официальной документации. Данная статья — (насколько я понимаю) про другое. Многие ведь действительно не идут дальше поверхностных оценок типа "фуу дурацкие let, почему не сделали как в С++". Автор же, как мне кажется, смог донести кое-какие принципы языка даже до тех, кто его впервые увидел. Пусть и на несколько дурацких примерах.
Всего голосов 4: ↑4 и ↓0+4
Не спорю, статья хорошая)
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr