Релиз Rust 1.30

Прочитал. Ничего не понял. Но, судя по схеме, слоем ниже у нее TiKV, у которой персистенс слой — RocksDB. Черт ногу сломит

Добро пожаловать: https://github.com/rust-lang/rust/labels/I-unsound 💥

Отлично, да хоть новый Curiosity ровер на расте пиши

Rust и не обещал абсолютную защиту.

Одновременно обещал и не обещал. Он как бы должен работать корректно из-за семантики языка. Но с другой стороны, это такой же софт, сделаный людьми, как и все остальное

Он обещал быть лучше C/C++ и это им удалось.

Теперь можно импортировать макросы в область видимости с помощью ключевого слова use.

Ппц. Срастание базового языка с языком макросов.

Сырые идентификаторы

Убожество. Сразу снижается читабельность кода.

Два новых улучшения в использовании use: во-первых, внешние пакеты теперь добавляются в prelude, во-вторых, use стал поддерживать импорт элементов в текущую область видимости с путями, которые начинаются на crate.

100 раз натыкался. Хотя это ж от неопытности.

Чувствую как проблемы препроцессора C++ будут и в Rust. каждый умник будет вставлять 100500 макросов и чтение/отладка кода певратится в веселье.

Быдлокодеров не хватит в проектах более чем на 500 строк. Начнется война с бороучекером и веселыми дженериками раста месяцов так на 3-4. Я на себе проверил фразу «да этот язык учится за выходные». Не ну когда ты плюсовик со знанием всяких хаскелей и т.д., то таки да - 2 дня и ты понимаешь раст. Но когда начинаешь свой проект строчек эдак на 10000-50000, понимаешь что нифига ты не знал. Система модулей чего только стоит. В которой надо понять какой модуль как импортируется и как у него будет область видимости.

Прописывание путей use - вот это истенное «удовольствие». Тупая фигня которая отнимает кучу времени, особенно после extern crate поднимать философские вопросы бытия кретов внутри модуля.

https://github.com/mit-pdos/noria

Поясните мне за это:
https://doc.rust-lang.org/book/second-edition/ch04-01-what-is-ownership.html

Читаем:

When the function is over, those values get popped off the stack.
The types covered previously are all stored on the stack and popped off the stack when their scope is over

WTF? В расте действительно перед выходом из функции отрабатывает стопочка pop'ов? Не накладно ли? Хотя я вот проверил:

fn main() {
    let x: i32 = 10;
    let y: i32 = 20;

    test(x, y);
}
 
 
fn test(a: i32, b: i32) {
    println!("{} {}", a, b);
}

то в начале функции sub rsp, 58h и перед выходом add rsp, 58h.

я плохо знаком с rust, можете в двух словах обьяснить в чём он лучше с++ ?

Всем, да.

Да в общем всем.

Не путай логику языка и конечный машинный код. Логически каждое значение освобождается. Компилируется это, конечно же, в одну инстркуцию.

безопасный язык, покрыт ли так тестами сам, как sqlite

Как SQLite вообще мало что покрыто тестами. Я, например, ни одного такого проекта не знаю. Ты слишком высокую планку ставишь.

Согласен. Но вот как раз языкам программирования, компиляторам как раз не помешала бы высокая планка. Понятное дело что рук на все не хвататет, в Rust еще много чего нужно делать и работают они хорошо. Но вот пока что ситуация не идеальная.

В Rust от максимальной стабильности компилятора и генерируемого кода была бы колоссальная польза, так как тогда правильно написаному коду на Rust без лишней магии, без unsafe, можно было бы серьезно доверять

Когда в языке есть RefCell, где динамическая, а не статическая проверка корректности, то приложение также может свалиться, как какая-нибудь программа на Си++. Другое дело, что в Rust это происходит крайне реже, чем на Си++, где меня не покидало постоянное чувство, что как будто ходишь по минному полю, особенно при написании серверного софта на Си++.

Вы путаете панику и segfault.

В С++ проблема не в том, что приложение может свалиться, а в том, что оно может не свалиться, а запустить /bin/sh, например. Если бы оно всегда сваливалось, было бы не так страшно.

Но когда начинаешь свой проект строчек эдак на 10000-50000, понимаешь что нифига ты не знал.

Бог миловал.

Система модулей чего только стоит. В которой надо понять какой модуль как импортируется и как у него будет область видимости.

Не замечал такого рода проблем. Хотя вещи типа pub(mod) я еще и не тыкал даже.

Прописывание путей use - вот это истенное «удовольствие».

Это про use some::long::path::to::module::item? Как я заметил, обычно стараются прокинуть нужные объекты из глубин иерархии поближе к корню с помощью «сквозного» pub use module::item;, чтобы за ними далеко ходить не нужно было.

Хотя вещи типа pub(mod) я еще и не тыкал даже.

mod(pub)

Синтаксис убогий, да.

Вышел Rust 1.30, не за горами Rust 1.31 aka «Rust 2018», в связи с чем разработчики просят вашей помощи: Требуется помощь в тестировании Rust 2018

Полторы страницы всего? Как хайп-то поутих

Согласен. И там в Си++ без valgrind по-хорошему никак. В отличие от Rust, где valgrind тоже бывает иногда полезен, но нужна такая проверка гораздо реже.

Полторы страницы всего? Как хайп-то поутих

Пропали основные критики, раньше они так раскручивали тему, что любой бы позавидовал. Оно и понятно, всё уже обмусолено. Раст, можно сказать, созрел. Вся надежда на тебя!

Ну, на основе вышесказанного, можно подвести итог, что пока не будут сделаны нормальные инструменты для сборки динамических раст-либ и програм, от них зависящих — расту в линукс дистрах не бывать

расту в линукс дистрах не бывать

Что ты хочешь этим сказать? Компилер раста уже есть в линукс дистрах, да что там линукс, он и в BSDях разных тоже есть.

Вот тебе свежий пример

В Убунту 18.10 появился ripgrep. Заходим на crates.io и видим что у него 10 либ зависимостей. Причем популярных

Заходим на packages.ubuntu.com и видим, что у него 0 (ноль) растовых зависимостей. В убунте он представляет из себя 1 бинарник размером 3.5Мб, со всеми зависимостями внутри

Любой уважающий себя мэйнтейнер никогда бы не поступил столь опрометчиво. Мэйнтейнер заботится о других мэйнтейнерах. Он опакетил бы по отдельности все (или хотя бы популярные) зависимости и собрал ripgrep, подключая их динамически.. Но, как утверждают тут на лоре, при пощи cargo сделать это практически нереально

Любой уважающий себя мэйнтейнер никогда бы не поступил столь опрометчиво. Мэйнтейнер заботится о других мэйнтейнерах.

Сомнительное утверждение.

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

Он опакетил бы по отдельности все (или хотя бы популярные) зависимости и собрал ripgrep, подключая их динамически.

А вообще, приведи примеры. Есть ли в линуксовых дистрах написанные на компилирующем в нативный код языке утилиты, для которых общие либы (тоже написанные на этом языке) выделены в отдельные пакеты? Естественно, если этот язык не C/C++.

В любом случае, от того, что один мейнтейнер собрал ripgrep статически, другим мейнтейнерам ни горячо, ни холодно

Для того, чтобы растовые утилиты массово стали приходить в дистры, необходимы общие библиотеки. Дистростоители не обрадуются десяткам-сотням утилиток размером под 10 мегабайт

Есть ли в линуксовых дистрах написанные на компилирующем в нативный код языке утилиты, для которых общие либы (тоже написанные на этом языке) выделены в отдельные пакеты?

Это что за такие я зыки и утилиты? На память приходит только Unison на Ocaml

Для того, чтобы растовые утилиты массово стали приходить в дистры, необходимы общие библиотеки.

Это утверждение нуждается в обосновании. Я поэтому и просил привести примеры массового прихода в дистры утилит с общими библиотеками на каком-либо компилирующем языке. Похоже, что единственные языки, удовлетворяющие твоему условию, это пока только C/C++. Программы на Go, Rust, Haskell, Ocaml (может кого забыл) в дистрах есть (не массово, конечно), но зависят они только от забинденных сишных либ, а свои либы вкомпиливают статически.

На память приходит только Unison на Ocaml

Глянул в арче и дебиане — unison зависит от gtk2, curses и libc. Окамловские либы, опять же, вкомпилены статически.

Дистростоители не обрадуются десяткам-сотням утилиток размером под 10 мегабайт

Вполне возможно, что утилитки размером под 10Mb меньшее зло, чем dll hell.

Программы на Go, Rust, Haskell, Ocaml (может кого забыл) в дистрах есть (не массово, конечно), но зависят они только от забинденных сишных либ, а свои либы вкомпиливают статически

Как минимум во фряхе хаскелевские либы и программы могут собираться динамически и собственно в портах полно пакетов с либами.

Да, действительно. Посмотрел в арче: тот же pandoc динамически зависит от нескольких хаскелльных либ.

I stand corrected, спасибо.

Выходит, с т.з. критерия spoonbob'а хаскелл популярнее раста.

А есть ли статистика по вкладу компаний в развитие компилятора раста? По типу той, что ежегодно публикуют про ядро линукса. Мне интересно, сколько процентов приходится на компании и сколько на энтузиастов. Похожую статистику про llvm, на котором базируется раст, тоже интересно глянуть.

Кстати, а что теперь с оригинальным растовским компилятором на ocaml, совсем забросили?

А есть ли статистика по вкладу компаний в развитие компилятора раста? По типу той, что ежегодно публикуют про ядро линукса. Мне интересно, сколько процентов приходится на компании и сколько на энтузиастов.

Я не встречал. Думаю, большую часть работы делают работники Mozilla.

Кстати, а что теперь с оригинальным растовским компилятором на ocaml, совсем забросили?

Его забросили еще году в 2010, когда Rust был мало похож на современный Rust.