Комментарии 50
На фотке Торвальдс же?
что особенно иронично если учесть, как Торвальдс сопротивлялся внедрению rust в код ядра линукса.
А фотография попала из этой статьи https://www.techspot.com/news/96037-rust-programming-language-join-linux-kernel.html
Вроде он сопротивлялся только появлению C++, для rust он выкатил список требований, которые они и удовлетворили.
Настолько сопротивлялся что вкатили поддержку в апстрим 6.1, в 6.3 будут готовы вливать драйверы.
Это иллюстрация к "сводить ошибки к нулю" :-D
Кстати servo недавно ожил.
Не сказать, что он умирал. Оксидация FF имеет довольно неплохой план и servo его пророк.
Новости идут до 2020-11-17 и потом два обновления 2023-01-16 и 2023-02-03. Два года перерыва.
После очередного административного апокалипсиса в Мозилле, дело почти заглохло. Stylo впилили, парсер медиафайлов влили, WebRender влили уже года полтора назад, но все так не выберется.
Целиком Servo никто в FF тащить не будет.
Интересно наблюдать, как мифологизация становится значимой частью Computer Science.
...когда был Торвальдс маленький, с кудрявой головой
Он тоже бегал в валенках по горке ледяной!
Возможно я не в курсе про какую-то концепцию. Но я не помню, чтобы в C/C++ было понятие транзакций памяти. Ссылка на статью в Вики про транзакционную память -- это совершенно другое понятие, которое к ручному менеджменту памяти имеет весьма опосредованное отношение
Можно подумать что все ошибки при написании кода сводятся к ошибкам при работе с памятью. Это просто фишка языка, которая есть почти у любого другого языка.
которая есть почти у любого другого языкаЭти «почти все» другие языки в основном обеспечивают безопасную работу с памятью через сборку мусора, что накладывает свои ограничения и создаёт свои проблемы. А в Rust — безопасная память через принудительное RAII.
RAII в некоторой степени помогает работать и другим фишкам языка, например fearless concurrency (при захвате мьютекса создаётся MutexGuard, который автоматически разрушается при выходе из области видимости, и вместе с этим разблокирует мьютекс).
вы меня не правильно поняли, я имел ввиду в принципе фишки отличающие один язык от другого. Просто в статье информацию преподнесли так, будто это панацея от всех проблем. Немного преувеличено как мне кажется.
Будто подход Rust не накладывает своих ограничений и не создаёт проблем. Впорос только в том, какие ограничения удобнее, и какие проблемы менее болезнены.
Но двусвязные списки всё же есть, причём в стандартной библиотеке. Да, под капотом у них unsafe, но публичный интерфейс полностью доступен из safe-подмножества. Можно долго спорить, считается это «честной» реализацией или нет, но тогда давайте не забывать, что где-то в глубине стека вызовов всё равно нет-нет, да и происходит обращение к ядру ОС, которое unsafe просто потому что FFI.
Но это не означает, что к безопасности и стабильности не надо стремиться. Те же языки со сборкой мусора (с которых +- начался этот тред) именно поэтому и появились: работать с памятью сложно.
Ну... В принципе, да имел в виду ту же самую проблему, но только в очередной раз она вылезла мне боком с совершенно другой стороны: попытка сделать простенький скриптовый язык поверх Rust библиотеки снова потребовала писать unsafe-код. Ну, потому что в скриптовом языке тоже нет концепции владения. Получается, что в экосистеме Rust безопасно можно писать только на Rust и в терминах Rust с серьёзными ограничениями на структуры данных и алгоритмы. ??♂️
Да чтоб я так безошибочно многопоток на Си писал...
Андроид, Хром и Мозилла сходятся на цифре 70. 70% уязвимостей так или иначе вызвано ошибками в работе с памятью.
Во вторых, borrow-checker часто ловит в том числе логические ошибки
В третьих, не borrow-checker-ом единым! У раста очень много других фишек, помогающих писать надёжный код. Option/Result вместо исключений, требование полноты для match, и многое другое — вынуждает программиста думать о всех путях выполнения кода. В том числе, когда что-то идёт не по плану. Возможные ошибки видны как на ладони, и просвечивают через сигнатуры. И они все должны быть обработаны, чтобы программа прошла тайпчек
И, по моему субъективному опыту, писать крупную долгоиграющую систему намного приятнее, когда гарантировано знаешь, где она может посыпаться, а где не может
О чём эта статья?
https://llvm.org/devmtg/2014-10/Slides/Baker-CustomHardwareStateMachines.pdf
Вроде, есть способы генерировать код для FPGA на llvm, в который и компилируется rust.
Правда, FPGA и PLC разные устройства (кстати, насколько? не в теме), так что придётся немного и железо поменять в лифте, а раз уже меняется, то можно и arm воткнуть. Разумеется с k8s и метриками.
Спасибо, а зачем на RTOS или Linux свой язык лестничной релейной логики. Кажется, можно написать на более привычном C? Я думал, там что-то на уровне отдельных транзисторов, а не SoC. Это не так?
Нет кода - нет багов и зависаний
Всё верно. Поэтому многие разработчики переходят на no-code
Похоже на речь евангелистов типа "Любите говно!"...
А потом узнал, что лифт не работал из-за сбоя программного обеспечения. Тогда он решил попробовать сделать язык программирования, который сводил бы такие ошибки к нулю. Чтобы даже начинающий разработчик мог бы написать код, который не зависал.
Какая элегантная подмена понятий.
Начинающий разработчик пишет программу для здания в 10 этажей (псевдокод):Пока(этаж<20) повторятьи она зависает.
пауза(1 сек);
О, а мне байку рассказывали, что для лифтов делают управление на плис, так как они доказательно верифицируются.
Ошибки типа переполнения буфера и выхода за пределы массива в языке стали невозможны в принципе.
Всмысле не возможны? Там встроенные проверки и программа падает при попытке записать что-то за границы массива? Как std::vector::at в C++?
Ну так это та же ошибка, только поведение при ней — аварийное завершение программы, а не возможная уязвимость.
if let Some(value) = vec.get(index) {...} как раз для подобных случаев.Можно обращаться и с помощью квадратных скобок — тогда да, запаникует.
Что будет, если этот Option программист попробует вывести или прибавить к счетчику?
А с записью как?
Ну вот, допустим, вам надо данные крипто-ключа записать в массив. Массив оказался коротким. Вижу 2 варианта: программа запаникует или надо проверять результат, вдруг ошибка вернулся. В любом случае, программа будет работать некорректно. Ну некуда ей этот ключ записывать, а что-то делать с обрезком бессмыслено.
От зависнувшего лифта не помогает. Предотвращает возможность эксплоита — да.
А ещё массивы и ко. знают, какова их ёмкость, так что можно явно проверить перед записью.
Вот вам небольшой пример как это может быть использовано (можете раскомментировать строки 3 и/или 4 если хотите посмотреть поведение для чуть других типов).
Тема лифта не раскрыта совершенно. Как он узнал что сбой был именно из-за ПО, что за баг там был...
У меня есть гипотеза, назовём её bug homeostasis, согласно которой забагованность программного обеспечения не зависит от того, насколько хорошо язык программирования и прочие инструменты защищают от ошибок. Суть в том, что чем более «безопасно» ощущает себя программист, тем более «спустя рукава» он работает, допуская всё тот же процент ошибок в итоге.
Индекс не может выходить за пределы массива? Нет проблем — напишем программу так, чтобы индекс в пределах массива в неверные элементы попадал.
Как сломанный лифт привел к появлению одного из самых популярных языков программирования