Comments 30
Хотел как-то посмотреть, как выглядят production-ready проекты на Rust. Похоже, многие проекты, которые можно найти на github, делались для изучения языка и впоследствие забрасывались. Можете порекомендовать что-нибудь production-ready и кем-нибудь реально использующееся на Rust?
Видел что часто https://github.com/BurntSushi/ripgrep советуют в ответ на подобное, как пример небольшого, довольно идиоматичного и быстрого кода.
Есть статейка с обзором кода проекта: http://blog.mbrt.it/2016-12-01-ripgrep-code-review/
В Mozilla Firefox уже часть кода на Rust.
И правда, с чего я решил что вопрос про исходные коды этих проектов? :(
то есть суть вопроса — взлетит или нет? го, шарп, цпп, или всё-таки раст? может всё-таки котлин во все поля?
мне хватает шарпа, ц\цпп и спецязыков на работе и ещё жабы немного. интересен котлин в степени уже бОльшей, чем некоторое время назад был интересен го. а гоу был интересен тем, что на нём достаточно просто создавать лёгкие сервисы с переносимым кодом. в котлин можно уже всё, включая андроид во все поля. можно ли котлин в сервисы с переносимым кодом так же, как в го — пока не понял.
так что пока смотрю на раст ровно так же, как на го, но знаю при этом, что у го история успеха толще.
Rust попал в нишу. По мне так Rust надежнее C++ (искать баги проще уже при компиляции) и нет дурацкого GC который есть в Go, Java, C#, Kotlin, D…
https://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/
Справедливости ради, они только пару компонентов переписали, остальная кодовая база у них всё ещё на Го и вроде, говорят, не собираются слезать. Но да, по их словам, памяти сэкономили много.
А есть pdf-версия этой версии?
Просто сохраните в pdf с этой страницы
Я собираюсь как-нибудь потыкать Rust, но меня снедают разные сомнения. Вот я хотел спросить об одном — может, кто-нибудь сможет его развеять. Как продвигаются дела с non-lexical borrow? Я просто слышу звон, и у меня есть впечатление, что когда это наконец появится, то стиль кода сильно изменится. Меня это здорово сдерживает — поскольку тыкать собирался не по какой-то необходимости а так, попробовать тёплая ли водичка, то хочется уже сразу писать идиоматично. Вместо этого есть ощущение, что сейчас придётся пробовать poor man's Rust, а уж потом, когда появится non-lexical borrow, вот тогда заживём и наконец я пойму, что такое идиоматичный код. По делу беспокоюсь, или мерещится?
Насколько я понимаю, принципиально ничего не изменится. Да и специально задумываться об этом, вроде, не приходится. То есть, иногда компилятор бьёт по рукам за код, который вполне мог бы быть корректным — приходится исправлять.
Самое неприятное, что мне встречалось — ситуация, когда нужно написать функцию, возвращающую ссылку на объект в контейнере, если он там есть, или добавляющую новый элемент и возвращающую ссылку на него.
Этот код не компилируется, так как время жизни возвращаемой ссылки включает весь код функции, в том числе и self.insert(...). То есть компилятор считает, что self менять нельзя даже после return v;, поскольку его часть всё ещё позаимствована возвращаемой ссылкой v.
fn get<T>(&mut self, key: &T) -> &u32 {
if let Some(v) = self.find(key) {
return v;
}
self.insert(key, 0)
}Сейчас советуют использовать два вызова find, что, конечно, менее эффективно:
fn get<T>(&mut self, key: &T) -> &u32 {
if self.find(key).is_none() {
return self.insert(key, 0);
}
self.find(key).unwrap()
}
https://doc.rust-lang.org/src/core/option.rs.html#667
https://doc.rust-lang.org/std/collections/hash_map/enum.Entry.html#method.or_insert
fn get<T>(&mut self, key: &T) -> &u32 {
{
if let Some(v) = self.find(key) {
return v;
}
}
self.insert(key, 0)
}
Не так красиво, но время жизни закончится там, где надо.
Не закончится: вопрос на stackoverflow с точно таким-же кодом.
Через месяц буквально сложности с borrow checker'ом уходят вообще на второй план и даже не задумываешься. Жутко не хватает готовых библиотек, кусков кода. В документации иногда вообще непонятно, что делать с той или иной библиотекой.
После С++ это как глоток свежего воздуха в этой нише.
А для проектов типа Diesel или Rocket всё ещё нужна Nightly-сборка? Те расширения языка, которые они используют (кодогенерация во все поля) собираются стандартизировать?
Diesel компилируется с Rust 1.17. Rocket все еще требует nightly. Потихоньку все это стабилизируется (процедурные макросы, например, были стабилизированы то ли в прошлой, то ли в позапрошлой версии)
процедурные макросы, например, были стабилизированы то ли в прошлой, то ли в позапрошлой версии
В 1.15 там же только "custom derive" был стабилизирован. Насколько я помню, полная стабилизация процедурных макросов это еще дело очень далекого будущего.
Выпуск Rust 1.18