Комментарии 36
Я выучил раст, нашёл 1 вакансию в Украине и 5 в мире, на украинскую провалил собеседование, американцы с европейцами отказали по причине отсутствия опыта с раст… у меня 6 лет опыта в разработке на дотнет, придётся дальше на шарпе писать...
Мне, пожалуй, повезло: раст изучал из любопытства (писал на С++), а работодатель (Украина) неожиданно сам меня нашёл. После этого, конечно, проще — удалось удалённую работу найти.
Думаю, что наличие хобби-проекта или участие в опенсорс разработки прокатит за опыт с растом. Понимаю, что найти на это время не всегда получается. С другой стороны, вспоминаю какой код писал на расте изначально и понимаю что некий период адаптации всё-таки требуется. Особенно, если на новом проекте не будет более опытных людей, которые помогут с этим.
и нзв крс: срз нстр на пзтвн лд
срз чвств себя *(микроконтроллером)
вдь чтб пнт мкркнтрл нжн дум как мкркнтрл
Вам точно понравятся арабский язык и иврит.
После Java наверное да, очень больно :D
Да, после такого особенно больно...
Лично мне больше нравятся fn, pub и impl, чем function, public и implementation. Писать короче и чтение кода они никак не затрудняют, наоборот, код становится сильно компактнее и яснее.
fn inc3<'a>(mut y : &'a mut * mut i32) -> i32 {
Под спойлером полный код фн, но ппр ё взв
unsafe
fn inc3<'a>(mut y : &'a mut * mut i32) -> i32 {
println!("y = {:?}", *y);
**y = **y + 3;
**y
}
А нахрена тут три раза mut?
Здесь проблема не в fn, и не в mut, а в том, что вы принимаете ссылку на указатель. Этот код не назовешь ни тривиальным, ни типичным. И может пояснить, зачем вы указываете лайфтайм у ссылки, который никак не используется?
А возник он из одной моей ошибки, когда я тупо не там поставил mut — компилировалось, но не работало, как хотел бы я, а не компилятор.
Сигнатура функции должна быть такой:
unsafe fn inc_three(y: &*mut i32) -> i32Это просто демонстрация читаемости — рабочий и компилируемый пример.
Назовите язык, в котором нельзя говнокодить.
Пример же в том, что Раст позволяет делать ошибки! (не говнокод) на ровном месте из-за синтаксиса.
Я уж с ужасом представляю, как будет выглядеть вызов классического Виндового АПИ с параметрами — коллбеками (указатели на функции, причем Сишные ABI).
Да, полностью согласен, это отталкивает. Меньше не всегда значит лучше.
А ещё больше отталкивает наличие большого количество "слов" в коде программы, несущих чисто "служебное" значение и не имеющих прямое отношение к логике программы. Например, "unwrap" и его вариации, встречающиеся постоянно, "cloned", "get_mut", "boxed".
Ещё в Rust много контейнеров, которые названы "дефолтными" словами, никак не описывающими их назначение. Обычно мне такие слова linter подчёркивает в других языках, как плохие. Например, Box. Из-за этого сильно страдает выразительность языка, как мне кажется.
Всё это меня смущает настолько, что по большей части именно из-за этого я до сих пор откладываю полноценное изучение Rust.
Любопытно, что опытные растоманы не считают синтаксис проблеммой от слова совсем, но существенный процент новичков недоволен.
Видимо это связано с теми же явлениями, что и в каком-нибудь Haskell. Ведь хаскелисты отлично умеют читать свои программы, но для остальных это больше тайные манускрипты, чем код. В данном случае чуть меньше всё это проявляется, но всё-таки.
Что угодно становится проще, если на это писать, конечно же. Просто таких ощущений у меня не возникает, когда читаешь код на javascript, С#, Ada, PHP, Java и даже Tcl. А тут возникают.
Например, "unwrap" и его вариации, встречающиеся постоянно
Использование unwrap не допустимо в конечном коде приложения, иногда его можно использовать, когда точно обработка ошибки не требуется, но это бывает крайне редко.
Ещё в Rust много контейнеров, которые названы "дефолтными" словами, никак не описывающими их назначение. Обычно мне такие слова linter подчёркивает в других языках, как плохие. Например, Box. Из-за этого сильно страдает выразительность языка, как мне кажется.
А можно подробнее? Box назван именно так, потому что то, что он содержит — это "упакованный" (boxed) объект.
Ну, "упакованный" объект — это что значит? Я вот не очень понимаю. Box как бы проводит аналогию с реальным миром (с коробкой), но назначение его или особенности устройства всё ещё не понятны при прочтении. Как слово-placeholder, которое можно заменить на что-то другое со схожим значением без потери смысла. Например Storage, Container, Holder или даже Any, Object.
В таких языках, как Java и C#, упаковкой называется перенос значения, которое обычно лежит в стеке или внутри другого объекта, в кучу (в Java упаковать можно примитивное значение, в C# — любую структуру).
Также этот термин иногда неофициально употребляется в языке JavaScript, где упаковкой называется то, что делает операция ToObject, а упакованными значениями — объекты классов Boolean, Number, String и Symbol.
Хм. Спасибо, такой специфики не знал, изучу.
Но всё-таки Box мне всё ещё кажется не подходящим названием, хоть и общеиспользуемым.
Ну вообще говоря счастливые пользователи Java 1.6+ могут и не знать термина, ибо автобоксинг и автоанбоксинг — божественный сахар языка. Ну и да, в java это больше вопрос способа хранения — в виде объекта или в види примитива (сырых данных). А храниться примитивы могут и в куче в виде полей объектов, расположеных в ней (а все объекты в java лежат только в ней, и только локальные примитивы могут существовать в виде данных на стеке).
ЗЫ за шарпы не скажу, не интересовался внутренней кухней...
Так оно и в C# автоматически работает. Но для производительности что там, что там следует знать когда именно это "автоматически" наступает и по возможности избегать этого "автоматически".
Не на пустом месте в Java есть интерфейс IntStream, и не просто так вместо него лучше не использовать Stream<Integer>
Да, "упаковку" не в Rust придумали: https://habr.com/ru/post/328052/
Читал с интересом, ожидая самого интересного — как же жава-проггерам легко и просто объяснят про заявленные главными темы — заимствование и времена жизни.
Оказалось, что
Rust для Java разработчиков