Ads
Comments 36

Я выучил раст, нашёл 1 вакансию в Украине и 5 в мире, на украинскую провалил собеседование, американцы с европейцами отказали по причине отсутствия опыта с раст… у меня 6 лет опыта в разработке на дотнет, придётся дальше на шарпе писать...

другие языки и парадигмы в любом случае полезно учить, для того чтобы стать лучше как разработчик (см. парадокс Блаба). Я до Раста в java, вообще раньше особо не задумывался как GC работает и ведет подсчет ненужных объектов, ну и про лайфтаймы не задумывался.

Мне, пожалуй, повезло: раст изучал из любопытства (писал на С++), а работодатель (Украина) неожиданно сам меня нашёл. После этого, конечно, проще — удалось удалённую работу найти.


Думаю, что наличие хобби-проекта или участие в опенсорс разработки прокатит за опыт с растом. Понимаю, что найти на это время не всегда получается. С другой стороны, вспоминаю какой код писал на расте изначально и понимаю что некий период адаптации всё-таки требуется. Особенно, если на новом проекте не будет более опытных людей, которые помогут с этим.

мн нрвтс этт яп. лкончн && крсв.
и нзв крс: срз нстр на пзтвн лд

срз чвств себя *(микроконтроллером)
вдь чтб пнт мкркнтрл нжн дум как мкркнтрл
Я как новчёк в расте, смеялся и плакал с вашего комменатария. Так коротко всю суть передали!

Лично мне больше нравятся 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
}

Здесь проблема не в fn, и не в mut, а в том, что вы принимаете ссылку на указатель. Этот код не назовешь ни тривиальным, ни типичным. И может пояснить, зачем вы указываете лайфтайм у ссылки, который никак не используется?

Это просто демонстрация читаемости — рабочий и компилируемый пример. Впрочем примерно так же выглядят интерфейсы при вызове Сишных функций.

А возник он из одной моей ошибки, когда я тупо не там поставил mut — компилировалось, но не работало, как хотел бы я, а не компилятор.
Это просто демонстрация читаемости — рабочий и компилируемый пример.

Назовите язык, в котором нельзя говнокодить.

Ну топик тут для Ява программистов — там подобное трудно соорудить.

Пример же в том, что Раст позволяет делать ошибки! (не говнокод) на ровном месте из-за синтаксиса.

Я уж с ужасом представляю, как будет выглядеть вызов классического Виндового АПИ с параметрами — коллбеками (указатели на функции, причем Сишные ABI).

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

А возник он из одной моей ошибки, когда я тупо не там поставил mut — компилировалось, но не работало, как хотел бы я, а не компилятор.

Да, полностью согласен, это отталкивает. Меньше не всегда значит лучше.


А ещё больше отталкивает наличие большого количество "слов" в коде программы, несущих чисто "служебное" значение и не имеющих прямое отношение к логике программы. Например, "unwrap" и его вариации, встречающиеся постоянно, "cloned", "get_mut", "boxed".


Ещё в Rust много контейнеров, которые названы "дефолтными" словами, никак не описывающими их назначение. Обычно мне такие слова linter подчёркивает в других языках, как плохие. Например, Box. Из-за этого сильно страдает выразительность языка, как мне кажется.


Всё это меня смущает настолько, что по большей части именно из-за этого я до сих пор откладываю полноценное изучение Rust.

Любопытно, что опытные растоманы не считают синтаксис проблеммой от слова совсем, но существенный процент новичков недоволен.

Видимо это связано с теми же явлениями, что и в каком-нибудь Haskell. Ведь хаскелисты отлично умеют читать свои программы, но для остальных это больше тайные манускрипты, чем код. В данном случае чуть меньше всё это проявляется, но всё-таки.


Что угодно становится проще, если на это писать, конечно же. Просто таких ощущений у меня не возникает, когда читаешь код на javascript, С#, Ada, PHP, Java и даже Tcl. А тут возникают.

Например, "unwrap" и его вариации, встречающиеся постоянно

Использование unwrap не допустимо в конечном коде приложения, иногда его можно использовать, когда точно обработка ошибки не требуется, но это бывает крайне редко.

Да, я подозреваю, что это что-то по типу намеренного unhandled exception в Python: если повезёт, что программа не крашится. И что так делать не надо. Но весь код на Rust, который я читал, пестрит использованием unwrap.

Когда делается прототип — вполне нормально. Хотя с использованием нормальных библиотек обработки ошибок типа snafu/anyhow, когда не нужно писать много бойлерплейта для конверсии типов ошибок, можно спокойно использовать ?.

Ещё в 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>

Не на пустом, но таки какой процент работающих с java им пользуется?

Очень хороший перевод, заслуженный плюс.

Читал с интересом, ожидая самого интересного — как же жава-проггерам легко и просто объяснят про заявленные главными темы — заимствование и времена жизни.

Оказалось, что все сами, тема сисек не раскрыта, в следующем номере, может быть…
Only those users with full accounts are able to leave comments. Log in, please.