Comments 19
Тема на самом деле интересная. Я прочитал все 3 статьи из цикла, и у меня сложилось впечатление, что языка, который обеспечивает надёжность нет. Языки из обзора либо слишком непопулярны (D, Ada), либо уже заброшены, либо C++ :) Но я для себя давно пришёл к выводу, что на любом языке можно писать надёжный код, если соблюдать дисциплину и наоборот. Например, недавно была новость про переписывание tmux на rust с 67к си кода на 87к строк unsafe rust кода, что определённо менее надёжно, чем tmux на си, который уже обкатан. Есть ещё языки с завтипами, например, agda, idris и т.д, но даже там никто не застрахован от ошибок, потому что так или иначе дело дойдёт до ввода вывода
Например, недавно была новость про переписывание tmux на rust с 67к си кода на 87к строк unsafe rust кода, что определённо менее надёжно, чем tmux на си, который уже обкатан.
В той новости сам автор прямо пишет, что это альфа версия и хобби-проект:
Автор решения советует не использовать эту наработку в том случае, если кто-то не готов мириться с частыми сбоями.
Давайте все-таки сравнивать сравнимое. Подождем рабочий вариант, если он будет конечно.
Я привёл, как пример того, что и на условно безопасных языках можно написать ПО, которое будет ненадёжным. Ничего против касательно этого проекта и rust в целом не имею. И наоборот на том же си при соблюдении некоторых правил можно писать вполне надёжный софт. В конечном счёте всё зависит от программиста
Согласен.
Просто я не вижу смысл обсуждать альфа-версии софта (давно известного), портированные с других языков.
И наоборот на том же си при соблюдении некоторых правил можно писать вполне надёжный софт.
Именно на С все же вряд ли. Лучше транслировать в полуавтоматическом режиме на С++, убрав потом сырые указатели, или на D (в котором подложили знатную свинью для этого, поменяв местоположение индекса массивов)
Еще есть Haskell, мы его используем для embedded разработки.
Насколько я понимаю ivory? А есть какие-нибудь хорошие обзорные статьи по нему, а то интересно посмотреть, а руки всё никак не дойдут?
ФП ЯП не рассматривались. Всерьез не рассматривались.
Тут не совсем ФП. Код пишется на haskell, но этот код генерирует код на си. Плюс ivory (библиотека, предназначенная для этого) даёт некоторые гарантии относительно получаемого кода.
Haskell – это один из самых императивных ООП языков ;)
А зря ;)
Тут дело в другом. ФП языки по своей сути являются надежными.
Но просто, как правило, они абсолютно непрактичны в использовании.
Да, можно привести пример Хаскеля, Эрланга или OCaml и вроде как есть области удобного их применения, например для парсеров, компиляторов, распределенных вычислений, но это без меня - я от этого далек...
Часть про Rust устарела процентов на 90. Вероятно и про остальные языки тоже.
Например в конце вот этого очень длинного комментария описано реальное распространение Rust.
поменяли логику контроллера ссылок NLL (я умудрился в учебнике наступить на пример, как в статье) сломав 220 сторонних библиотек, которые как зависимости утащили за собой еще 2000.
Это неправда. Вы можете запустить те самые примеры из учебника даже на последнем компиляторе с edition="2015", и они будут работать. И библиотеки с edition="2015" можно вызывать из кода с edition="2024", будет (почти всегда) компилироваться и работать.
Нарушения обратной конечно совместимости были, но их очень мало, а не так как вы пытаетесь представить.
стабилизировали alloc! (это простите основы), переписали стандартную библиотеку std кусками
Перенесли большие куски кода из std в core и alloc. Скажите, в каком языке вы сможете пользоваться большей частью std без рантайма и даже без кучи?
Да, конечно что то устарело.
А что то - нет. Сегодняшняя Почему компилятор Rust такой медленный? и недавно была такая же - Почему Rust так мало волнует производительность компилятора. Мне это было очевидно еще тогда, в 2019.
А что касается обломов компиляции примеров с растбука - ну видимо мне просто повезло тогда.
Перенесли большие куски кода из std в core и alloc. Скажите, в каком языке вы сможете пользоваться большей частью std без рантайма и даже без кучи?
В BetterC, например. Это базовое требование для поддержки baremetal. Так что во всех ЯП с таким специалитетом.
Хотя надо еще уточнить, как мы понимаем разницу между std и рантаймом...
А что то - нет. Сегодняшняя Почему компилятор Rust такой медленный? и недавно была такая же - Почему Rust так мало волнует производительность компилятора. Мне это было очевидно еще тогда, в 2019.
По моему опыту, скорость компиляции (инкрементальной) примерно одинаковая с С++. В работе с матрицами точно быстрее, где-то медленнее. В целом меня устраивает.
В последней статье правильно указали про lto, в текущем проекте (верхний крейт 40kloc) инкрементальная компиляция 4-5 секунд, но если выключить lto то 1-1.5 секунды.
Не инкрементальную делаю наверное раз в пол года, когда обновляю компилятор, так что вообще не важно. И в последней статье как-раз про то, как её ускорить на билд сервере.
В BetterC, например. Это базовое требование для поддержки baremetal. Так что во всех ЯП с таким специалитетом.
Ну в С и С++ с этим как-то грустно, BetterC пока не пробовал.
Надежное программирование
А где erlang?
И как там с надёжностью промтопрограмированая на chatgpt ?
ps: Вообще человеки уже давно придумали как делать надёжные системы из не надёжных подсистем, а так же оценивать вероятность их отказа. Так что дублируем системы добавляем watchdog-и и ваш яп тут нафиг не нужон. Особенно если ваше супер надёжное по работает на не надёжном железе.
Надежное программирование — часть 3. Финал (2019)