Comments 23
Краткое содержание статьи:
1. Язык Rust это очень хорошо.
2. На нём много чего написано - см. список.
3. Будущее Rust выглядит ярким и многообещающим. (Примечание. Язык создан э... от 8 до16 лет назад (смотря как считать)).
-----------
А если серьезно - интересно было бы сравнение какого-нибудь перемножения матриц на Си и на Rust.
Ой! Всё уже есть.
https://users.rust-lang.org/t/looking-for-help-understanding-rusts-performance-vs-c/30469/6
"Наивный алгоритм в Rust был почти в 2,5 раза медленнее, чем в C++." (А дальше обсждение, что делать и как быть).
-----------
А не GPT-3 ли написал эту статью?
Согласен, в последнее время статьи про раст всё больше напоминают нечто написанное нейросетью. Какое то вечное повторение двух тезисов с кривым переводом
Наивный алгоритм в Rust был почти в 2,5 раза медленнее, чем в C++
Звучит так, будто там какой-то фатальный недостаток языка обнаружился)
В смысле? Это скорее тогда у Си есть "фатальный недостаток". )
https://neolurk.org/wiki/Фатальный_недостаток
Ну, в среднем есть, потому раст и изобрели. Начиная от всяких segfault конструкций никак не валидируемых без тонн анализаторов или ChatGPT и кончания миллионом небезопасных функций а ля sprintf, породивших десятки тысяч CVE.
В примере, в котором Rust медленнее в 2.5 раза использовалось индексирование массива с проверкой. Если бы вы удосужились прочитать сообщения ниже, то увидели бы, что об этом написали, показав, что код с get_unchecked (без проверки) такой же быстрый, как и C/C++.
Я не знаю сколько поколений пройдёт, прежде чем люди будут говорить, что Rust по скорости ничем не хуже, чем C/C++, даже лучше, если проект не заканчивается на тупом перемножения матриц.
О статье и авторам подобных статей:
Она скучна и уже осточертели эти все замеры и рассказы про Rust. Хватит, делайте другой контент, где вы показываете как на Rust можно делать крутые штуки.
с другой стороны компилятор должен уметь такие проверки удалять в тривиальных случаях типа цикла, этого ещё не завезли?
Там дальше был пример для слайсов и там удаляются, возможно проблема в том что вектор изменяемый
Ждём reproducible builds
Хм, а разве не уже? cargo build --locked вроде как раз про это.
Процедурные макросы (и в особенности shadow-rs) передают привет.
Возможно Rust и хорош, но легаси на Си/C++ оооочень много и как бы rust не был хорош от сишки мы не избавимся ещё очень долго.
Для новых проектов подойдёт возможно, но в embedded разработке он вроде не так развит
Для embedded пойдёт, главное не забывать везде вставлять "unsafe".
> легаси на Си/C++ оооочень много
Знаю кое-кого, кто часть легаси с плюсов на раст переписал.
Цитата из общения:
> Написали один новый сервис на Rust, и он нам так понравился, что решили всё новое писать на нём, а некоторые старые даже переписать.
Amethyst
Аметист умер и фактически отдал свои наработки в Bevy, какие смог. Прочие околоигровые проекты.
Год назад выбирали язык на который переписывать высоконагруженный сервиcs. Было 3 варианта:
Golang, C++, Rust. После небольшого исследования в неделю, остались C++ и Golang. По итогу выбрали последний.
Хотели выбрать C++ он все же немного в наших задачах быстрее golang особенно в вопросе бинарных деревьев. Но победила быстрая разворачиваемость Golang. Притом базовых функций unsafe для доступа к DLL/SO библиотекам хватает. Собственно модуль который работает с бинарными деревьями написан на C++ и подключается в Golang
Почему не Rust ответ дали те люди которые и на C++ и на Rust. Когда в задаче всплывали сторонние библиотеки DLL и часть чужого кода С/С++ они сами же и отговаривали от Rust. Дополнительно поясняя что "какбэ" в данной задаче еще и жуткая "многопоточность" и опыта на C++ в этом у них значительно больше. И это мнение 10-ка человек. Притом когда я спрашивал ребят, а зачем Rust-то учили. Все без исключения ответили что-то из разряда:
"Появилась задача на хайпе, решили попробовать что-то новое"
Моё личное мнение после исследования такое, отвечу с точки зрения бизнеса:
1. Найти другого программиста на С++ проще, чем искать на Rust. Я говорю не о разработчиках средней руки, а именно о тех кто решает сложные задачи.
2. Прибавки в скорости по бенчам по сравнению с С++ не увидел. Либо она настолько ничтожна что в современном мире можно списать на погрешность
3. Под С/С++ написано больше чем много. Если стоит вопрос подключения библиотек сторонних и не дай бог еще они "закрытые". Несмотря на совместимость какую-то и возможность подключения (хотя лично мне кажется она такая же как на golang, просто чуть лучше) я с трудом могу представить ситуацию:
"Нам нужно сделать приложение. Будем использовать 10 библиотек готовых, проверенных на C++ [список]. Поэтому очевидно что наше приложение будет на Rust"
4. Не мог не обратить внимание на то что те статьи и комментарии которые я читал еще тогда, собственно как и эта статья напоминает: "Rust это круто и узнав его ты станешь элитой. C++/golang/python....[плохое слово]". Очень мало статей банально на реализации действительно сложных задач. 95% статей собственно как это.
А теперь по статье:
"Проекты, такие как QUIC и HTTP/3"
насколько мне не изменяет память, это Cloudflare открыла исходники на языке Rust. И на сколько я помню там Google делал на C++ изначально. А то что Cloudflare решил на Rust не говорит ни о чем. Захотели и сделали. Могут себе позволить.
"Rust и Веб-разработка"
С трудом представляю реализацию всего этого, код ради кода. Мы хоть не пользуемся контейнерами типа кубов, но пользуемся микросервисной архитектурой. Последнее что приходит на ум вставлять в JS бинарный код чтобы сцеплять их с языком программирования. Хотя реализация REST/GRPC вполне самодостаточная и не требует специфичных знаний для 99.99999% веб приложений. Могу ошибаться конечно, но выглядит как какая-то херня.
И на сколько я помню там Google делал на C++ изначально.
Microsoft сделал свою реализацию протокола QUIC на C (даже не на C++).
Есть Компонентный Паскаль, Оберон-2...
Верное средство сделать Rust "незаменимым" перепишите на нём код Cobol'а
Язык программирования Rust: безопасность, производительность и преимущества