Comments 78
Попробую высказать критику на критику и дополнения. Я соглашусь с вами в двух пунтках:
- Rust еще слишком молод. Думаю, следствием этого являются пункты "Набор инструментов", "Интеграция", "Производительность" и "Unsafe". Есть основания полагать, что со временем будет происходит улучшение в этом плане. Ошибки есть и в GCC (сам видел).
- Rust сложен и имеет более крутую кривую входа
Я бы еще добавил, что проблема в том, что Rust позиционируется как более безопасный язык, чем Си, но компилятор он слишком неформализован и активно развивается, чтобы быть сертифицированным для применения в каких-то реально safety-critical задачах, где, к примеру, сертифицирован лишь какой-нибудь IAR.
Еще из недостатков (как следствие молодости) добавлю малое количество библиотек. На С++, не говоря уже о С, больше. Захотел я GUI писать и приуныл. Пока что самая зрелая — веб-гуи на WASM, yew.
Не всё программирование является системным
Не соглашусь. Rust дает преимущества и не в системном программировании, не за счет модели работы с памятью, а за счет своей системы типов (ADT, pattern matching и все такое). Например, подход Option вместо исключений может сделать более понятным (по сигнатуре видно) и безопасным. Но проблема в том, что как, уже сказано, Rust имеет сложности, и все равно придется думать о владении, памяти, лайфтаймах и всяких Rc<RefCell>
Я бы еще добавил, что проблема в том, что Rust позиционируется как более безопасный язык, чем Си, но компилятор он слишком неформализован и активно развивается, чтобы быть сертифицированным для применения в каких-то реально safety-critical задачах, где, к примеру, сертифицирован лишь какой-нибудь IAR.
Для safety-critical я бы посоветовал упомянутую в статье Аду в режиме SPARK.
Там есть контракты, которые в C++ уже давно обещают, но никак не завезут, формальная верификация, много приятностей вроде параллельности из коробки и значений нестандартного размера (вроде массива из 8 элементов по 3 бита каждый) и удобочитаемый синтаксис. Есть, правда, и суровый минус — писать на этом тяжело. Впрочем, это можно считать и плюсом: набирая Очень_Длинный_Идентификатор_Из_Стандартной_Библиотеки_Языка_Ада программист успеет ещё раз обдумать реализацию. И какой нибудь Unchecked_Deallocation явно говорит о том, что надо всё перепроверить.
Ada безопасна для памяти, если не использовать динамическую память (никогда не вызывайте free).
Впрочем, с высоты моего опыта (аж одна полноценная программа на Аде), динамическая память там нахрен не сдалась, всё и так нормально работает.
Как только нет динамической памяти с указателями (или есть GC) и нет многопоточности, то все языки становятся надежными, как Раст =) Остальное плюс минус мелочи.
Впрочем многопоточность тоже минорный фактор в этом сравнении.
Между прочим, правила MISRA C тоже запрещают malloc/calloc/free.
Аналогичного результата в С получим с -fsanitize=bounds
#include <stdio.h>
int main(void)
{
char buf[5];
char buf2[5];
int m = 1000000;
sprintf(buf2, "%d\n", m);
sprintf(buf, "%d\n", m);
printf("%s%s", buf, buf2);
return 0;
}
$ gcc -fsanitize=bounds -o oob ./oob.c
$ ./oob
1000000
100001000000
Тишина, все довольны. Или я что-то не так делаю?
Собственно, это было выдвинуто на премию C’s Biggest Mistake
Почему аду, а не агду?
А есть ли у агды стандарт? Все нормативные документы (вроде ISO 26262) требуют наличия стандарта для языка программирования при использовании его в safety-critical областях, дабы через условные 20 лет в случае катастрофы эксперты вооружились этим стандартом и проверили, что код был написан правильно (или неправильно), а не гадали, что делает какой нибудь оператор вроде [@!], удалённый из языка 15 лет назад (а историю коммитов потеряли 10 лет назад при переезде на другой сервер). На аду есть стандарты ГОСТ и ISO, на си — ISO, даже на яваскрипт есть стандарт ECMA. Яваскрипт, правда, не проходит из-за динамической типизации, так что мы вряд ли увидим ракету, которая сложила -2 и 10 и, получив -210, улетела в сторону ближайшей чёрной дыры хвостом вперёд.
PS Я сам люблю функциональное программирование, но это не те задачи, в которых его сейчас можно применять. Мир к этому ещё не готов.
этакая бюрократическая верификацияНу так бумажки — это же самое главное! Мы живём в мире победившей бюрократии.
Но если хочется что-то на самом деле доказать, то они не лучший выбор.Как минимум SPARK можно статически проверить на соответствие программы спецификации и на отсутствие исключений. Не верифицируется только стандартная библиотека (прувер считает, что в ней нет ошибок), но все контракты для неё прописаны и их соблюдение будет проверено.
Наличие шильдика ISO не защищает магическим образом от аналогичной потери чего-нибудь при переезде на другой сервер, а агдой всё-таки пользуется достаточно много людей, чтобы распределённая природа гита взяла своё.Стандарт фиксирует определённое состояние языка на некий момент времени. Ребята из ISO уверены, что это важно, и я им доверяю. А гарантировать, что агдой будут пользоваться спустя сколько-то лет никто не может, вдруг выйдет какой-нибудь Coq2, который будет лучше и на который все переедут. А напечатанный на бумаге стандарт прекрасно пролежит в библиотеке лет 200.
А насколько выразителен язык спецификации? То, что я сходу нагуглил, говорит о SMT-разрешимых VC, а это заведомо довольно слабая штука.Я, в общем то, нагуглил то же самое. У спарка ограничения довольно серьёзные. Описывать свой язык — это к дружной компании из агды, идриса и кока. Ада и спарк, это скорее, проверять, что протокол общения с каким-нибудь исполнительным механизмом не может быть нарушен.
А то я просто сейчас вот пишу недостатью, где описываю какой-то модельный язычок, и в этой своей агде я описываю язык и доказываю формально всякие интересные свойства этого языка. Можно так в аде?
Кстати, вот тут есть справка по тому, что спарк может. А там в конце в разделе Alternative Provers скромно так говорят, что можно в параметрах командной строки написать
--prover=Coq, что уже несколько расширяет возможности языка.Лучше всё ж доверять всего лишь ядру проверялки, а не ядру проверялки + стандартной библиотеке.В стандартной библиотеке есть код, на который проверялка ругается. Сырые указатели, дёрганье ОС напрямую и т.д. Остаётся надеяться, что разработчики проверили корректность работы всего этого добра.
это, опять же, исключительно вопрос тулинга, а не какая-то фундаментальная недоработкаВот только задумались о такой нужной вещи только разрабы хаскеля. Я, например, о таком для фортрана мечтаю, но оно и близко не предвидится.
>Не соглашусь.
Ну а почему? Реально же не всё. Если бы даже Rust был пригоден только для системного — это разве было бы реально серьезным недостатком?
Ну и наборот тоже, вот скажем упоминание kotlin в одном контексте вас разве не смущает? Вот уж котлин-то вообще для системного программирования скорее всего не годится. Ну и ничего, никто не жалуется, есть ниши, где он хорош — ну и прелестно.
Я занимаюсь разработкой высокопроизводительного кода, часто нам нужен именно "чемпионский" код — показать самые высокие на рынке бенчмарки. Для меня очень важна скорость работы кода и иногда мне не хватает C.
В качестве практического примера приведу быстрые парсеры. В моем случае для разработки быстрого HTTP прасера понадобился не только GOTO, которого нет в Rust, но еще и computed labels — это уже compiler specific расширения для C.
Т.е. вот, есть реальная, не такая маленькая, задача, которую C решает лучше Rust. Но я не видел ни одной задачи, которую Rust решает лучше C. Удобство и быстрота разработки — возможно, но не скорость работы.
Если мучительно отлаживать указатели на C, то мы используем C++ с его smart pointers, RAII и пр. (Я могу вспомнить пару плохонаписанных, не наших, C проектов, которые мы переводили на C++ и в наиболее геморойных местах заменяли C указатели на smart pointers). В C++ можно всегда и просто встроить код на C, который будет работать очень быстро: совместимость с C — ключевое свойство C++ для системного программирования. C Rust, как и с D (тоже была такая 'лучшая' альтернатива C++), будут еще телодвижения на совместную компиляцию с C.
А еще видел неплохое, относительно нейтральное, сравнение C и Rust.
Но я не видел ни одной задачи, которую Rust решает лучше C. Удобство и быстрота разработки — возможно, но не скорость работы.
Вот тут есть некоторые задачи, которые Rust решает быстрее: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html
Значит ли, что в принципе это возможно?
Давайте посмотрим на первый бенчмарк Rust и C. Во-первых, эту программу на Rust, как многие другие для этих бенчмарков, написала команда разработчиков Rust — коментарий из копирайта:
contributed by the Rust Project Developers
Я не могу оценить реализацию самого бенчмарка на Rust, но копирайт заставляет думать, что там сделано хорошо.
Реализация на С https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-gcc-3.html — достаточно короткая реализация на OpenMP и APR, но явно не оптимизировалась вообще.
Не очень хороший сайт с бенчмарками по двум причинам.
1) Формулировка критериев оцениявания решения размыта. Заявляется, что типа решение должно быть "идиоматическое" но что это значит определяет левая пятка владельца бенчмарков. Отсюда там у него были истории что он то забанит решения то разбанит.
2) Гоняется это на старом по меркам 2020 железе.
Upd. Да что далеко ходить. Прямо на вашом примере
As a practical matter, the myriad ways to custom allocate memory will not be accepted.
Please don't implement your own custom "arena" or "memory pool" or "free list" — they will not be accepted.
Cмотрю топ2
using MemoryPool = std::pmr::monotonic_buffer_resource;use typed_arena::Arena;¯\_(ツ)_/¯
в большинстве случаев сравнивать результат надо при сравнимых трудозатратах. Потому что если абстрактный Вася напишет на том же расте за вдвое меньшее время, это значит не только что его решение на 20% медленнее, но и то, что он может потратить оставшееся время на оптимизации боттлнеков. Ну или, чаще, решения других задач.
Вася на Rust не напишет в 2 раза быстрее, потому что "Вася" — это средний программист, который о Rust только слышал, в бою его не пробовал. Начиная новый проект, мы знаем, что на рынке много C/C++ разработчиков, много наработанных библиотек, инструментариев и просто ответов на StackOverflow.
Новый язык — это для энтузиастов, кто готов вечерами посидеть с багами в новом языке, поучить матчасть и пр. Вот, и выбирайте как скоротать долгий осенний вечер — выучить новый язык или лучше разобраться в архитектуре и компиляторе знакомго языка.
Мой абстрактный Вася на си породит такое гавно что оно будет падать в половине случаем и отлаживать его ещё два года. На расте даже питонист может настаковерфловить решение за несколько дней =)
C Rust, как и с D (тоже была такая 'лучшая' альтернатива C++), будут еще телодвижения на совместную компиляцию с C.
Какие? Ежедневно компилирую вместе D и C без каких-либо проблем.
Я имел ввиду, что из C++ программы я могу заинклюдить C хедер и в общем случае (не учитывая, напирмер, использование new идентификаторов в C) это "работает из коробки". Есть интеграция из C++ в C через extern "C". Так или иначе, но С++ наиболее совместим с C. Например, наткнулся на такой пост про использование C хедеров из D: https://atilaoncode.blog/2018/04/09/include-c-headers-in-d-code/ .
»GOTO"
«Удобство и быстрота разработки — возможно, но не скорость работы»
Сам топи урановые ломы во ртути
PS: я кстати очень надеюсь, что это ваше Си просто запретят. Ну как нельзя ездить по дорогам общего пользования на автомобиле без тормозов и ещё многих вещей.
Потому что сперва у вас «лучшие бенчмарки на рынке» и «чемпионский код», написанный методом «мамой клянус, надёжно работает», потом у вас ХХХХ прибыли, а когда в вашем чемпионском коде находят уязвимости, у других людей возникает 100*XXXX убытков.
А к тому времени с вас и взыскать нечего — вы прибыль уже использовали, дома купили, детей завели. Было бы конечно неплохо дома у вас конфисковывать вместе с детьми, но в современном мире так не принято. Поэтому обойдёмся полумерами.
Переживёте вы поди без чемпионства, без высокой прибыли и без первенства на рынке. Хотите чтобы не тормозило — уймите фантазию фронтендеров.
"системный язык программирования" — это очень неопределенный термин, как его понимать? это значит что на Расте можно только драйвера или ядро писать? — Явно ответ нет! Можно и веб-странички писать при желании, не спроста там впилена поддержка WebAssembly.
Единственный "аргумент" против раста это лайфтаймы, но их просто надо понять, и в большинстве тривиального кода они не используются.
Мне вот тоже видится, что применение Rust шире ниши низкоуровневых системных задач. Но я уже писал статью на этот счет: https://habr.com/ru/post/504622/
В Rust также нет аналогов для идиомы pimplне хватает forward declarations и разделения объявления/реализации?
Динамическое связывание («в Rust должен быть стабильный ABI») — не думаю, что это сильный аргумент. Мономорфизация фундаментально несовместима с динамическим связыванием, и если вам действительно нужно, то есть C ABIоборачивать туда-обратно через C ABI неудобно и накосячить можно практически везде, даже из плюсов, которые к сям явно ближе.
Я действительно думаю, что здесь можно улучшить положение вещей, но вряд ли речь идёт о специфичных изменениях именно в Rust.там по ссылке человек предлагает сделать раст-специфичный ABI на замену сишному. Кажется, такое в принципе не может взлететь?
После того, как освоил Rust в достаточной мере, на C становится писать невозможно: если до этого писал и не думал, что тут может быть какая-то проблема, то после достаточно плотного знакомства с Rust ты понимаешь, что то нельзя, это нельзя, и надо проверить, не происходит ли вот этого… (за чем в Rust следил компилятор), и в итоге оказывается, что просто невозможно за всем уследить и всё необходимое проверить.
Сложность Rust имеет двойственную природу.
С одной стороны, в языке присутствуют мощные, и от этого довольно сложные для новичков концепции, которые, однако, упрощают разработку любой программы, которая чуть сложнее, чем hello world. Такая сложность является препятствием только при первом освоении языка, а в работе она собой компенсирует значительную сложность самой программы. Да, вы можете взять язык сильно проще, но потом будете дольше устранять проблемы в своем коде, особенно если его много и он многопоточный.
С другой стороны, многие красивые концепции Rust имеют особые случаи и исключения, которые не дают по-настоящему расслабиться. И вот эта сложность действительно является препятствием, но она во многом следствие молодости языка.
Можете привести пример исключений из красивых концепций? Мне кажется, что, примером исключений из концепций является C++, который (по моему скромному опыту, я больше по Си) состоит из исключений и замороченного поведения чуть менее, чем полностью. (Например, я все еще немного вздрагиваю, когда надо возвращать что-то из функции. Ну да, guaranteed copy elision, но похоже на магию).
Попробуйте async метод в трейте обьявить.
Нет специализации, impl Trait можно использовать только для функций, const generics до сих пор не стабилизированы — из-за этого небольшой адок при работе с массивами, по сравнению со срезами, auto Trait можно использовать только внутри std, даже некоторые фичи паттерн-матчинга еще не работают: хорошо, что недавно стабилизировали паттерны [..], но вот так до сих пор нельзя:
let tuple @ (a, b) = (1, 2);error[E0658]: pattern bindings after an `@` are unstable
--> src/main.rs:2:18
|
2 | let tuple @ (a, b) = (1, 2);
| ^
|
= note: see issue #65490 <https://github.com/rust-lang/rust/issues/65490> for more information
Не знаю, как это спросить так, чтобы не выглядело, будто я тролль, но попробую. Вот попадаются статьях в упоминания Ada. Народ это всерьёз или ради хохмы? Ну, просто я не знаю, кто реально её использует, а вакансий с ней я не видел вообще ни разу, при том, что даже Haskell и Delphi периодически попадаются.
Отдельные вакансии на Аду встретить тяжело, так как ищут не абстрактного программиста на Аде, а разработчика ПО систем авионики или специалиста по ПО космических аппаратов. Знание предметной области в данном случае важнее знания языка программирования.
Ну и вот, например, любопытный документ.
Ну вот список некоторых компаний, которые используют Rust в проде:
https://www.rust-lang.org/production/users
Давайте развернем столы, и спросим: а блокчейн где-то нужен?
Ну кроме шуток, это эффект популярности и хайпа, не более. В блокчейнах традиционно множество матана и пруфов корректности кода, т.к. за ваши денюжки будет отвечать не банк перед регуляторами, а каждый вася пупкин на районе с копией майнера на кофеварке. Раст им хорошо подходит по надежности. Пусть пишут, просто зацикливаться на этом не надо.
PS пишу как человек, почти устроившийся на такую работу, но вовремя заботавший матчасть.
Совсем недавно проскакивала новость, что производитель уличных повозок Segway обанкротился, потому что продавал дорогие и надежные товары, которые насытили рынок, и компании продавать стало попросту нечего (а переориентироваться на продукты попроще что-то помешало, если я правильно понимаю).
Вот это мне напоминает ситуацию с Rust — можно напрячься и написать что-то максимально безбажное сразу, по цене длительности первичной разработки. Только рынок живет по другим правилам — чирик-чирик и в продакшен, и скорость первичной разработки становится ключевой, да и покушать на пост-релизной поддержке можно.
Время еще не пришло
Вообще остаются всего несколько незакрытых вопросов, мешающих языку войти в мейнстрим, и все они ИМХО связаны с переиспользованием кода — динамическая диспетчеризация в кругах растеров штука немодная, ею просто никто не занимается (хотя ее регулярно спрашивают), на расширение структур данных и вовсе смотрят как на врага, так что приходится колхозить ансейфы, NLL работают раз через три, приходится либо копипастить, либо воевать с сигнатурами методов. Остальной язык несложный и отлично дисциплинирует.
Я думаю первостепенное значение играет количество и качество имеющихся библиотек в экосистеме, поэтому для Rust важно, чтобы он был популярен в Open Source. Когда количество библиотек перевалит за критическую черту, бизнесу станет выгодно его использовать. А если так, то становятся важны в первую очередь те качества, которые могут способствовать распространению Rust в среде свободного, а не коммерческого ПО.
Rust, Haskell и Powershell. Без компиляторов (их там всё равно никто не потянет), только документацию.
Rust — чтобы продемонстрировать, что переменная после перемещения должна становиться недоступной, а не содержать мусорные данные.
Haskell — чтобы объяснить, что ФП — это не куча скобочек, а более глубокая концепция.
Powershell — чтобы показать как должен выглядеть истинный unix way… и что может родиться если шеллы не будут следовать ему изначально.
Powershell — чтобы показать как должен выглядеть истинный unix way… и что может родиться если шеллы не будут следовать ему изначально.unix-way это в первую очередь про совместимость. Сделать очередное проприетарное решение на замену стандартного — вот ни разу не unix-way
Ну вот потому и было бы неплохо, если бы изначально было стандартное решение похожее на Powershell, под которое бы все с самого начала подстраивались.
Разумеется, под "похожестью" я понимаю объектный конвейер, а не жуткие многословные команды.
А почему тогда не nushell?
Разумеется, под «похожестью» я понимаю объектный конвейер, а не жуткие многословные команды.конвеер из многословно описываемых объектов или жуткие многословные команды, хм, я даже не знаю что выбрать…
Насколько я осведомлен, пош неплох как инструмент для виндовых сисадминов. Чтобы стать заменой баша, альтернатива должна быть открытой, кроссплатформенной и стандартизованной.
Насколько я осведомлен, пош неплох как инструмент для виндовых сисадминов. Чтобы стать заменой баша, альтернатива должна быть открытой, кроссплатформенной и стандартизованной
Не фанат повершелла, но он открыт и кроссплатформенен. Не знаю что именно вы подрузамеваеваете под станадртизован.
Исходники и сборки под линуксы и маки лежат на гитхабе
github.com/PowerShell/PowerShell
Попробуем выдвинуть аргументы против Rust