Pull to refresh

Comments 50

что особенно иронично если учесть, как Торвальдс сопротивлялся внедрению rust в код ядра линукса.

Вроде он сопротивлялся только появлению C++, для rust он выкатил список требований, которые они и удовлетворили.

А есть подробности? Интересно почитать, но не гуглится этот список

Это иллюстрация к "сводить ошибки к нулю" :-D

Не сказать, что он умирал. Оксидация FF имеет довольно неплохой план и servo его пророк.

https://servo.org/blog/

Новости идут до 2020-11-17 и потом два обновления 2023-01-16 и 2023-02-03. Два года перерыва.

После очередного административного апокалипсиса в Мозилле, дело почти заглохло. Stylo впилили, парсер медиафайлов влили, WebRender влили уже года полтора назад, но все так не выберется.

Целиком Servo никто в FF тащить не будет.

Интересно наблюдать, как мифологизация становится значимой частью Computer Science.

...когда был Торвальдс маленький, с кудрявой головой

Он тоже бегал в валенках по горке ледяной!

становится

"Just For Fun" была издана в 2001 году )

Возможно я не в курсе про какую-то концепцию. Но я не помню, чтобы в C/C++ было понятие транзакций памяти. Ссылка на статью в Вики про транзакционную память -- это совершенно другое понятие, которое к ручному менеджменту памяти имеет весьма опосредованное отношение

Можно подумать что все ошибки при написании кода сводятся к ошибкам при работе с памятью. Это просто фишка языка, которая есть почти у любого другого языка.

которая есть почти у любого другого языка
Эти «почти все» другие языки в основном обеспечивают безопасную работу с памятью через сборку мусора, что накладывает свои ограничения и создаёт свои проблемы. А в Rust — безопасная память через принудительное RAII.
RAII в некоторой степени помогает работать и другим фишкам языка, например fearless concurrency (при захвате мьютекса создаётся MutexGuard, который автоматически разрушается при выходе из области видимости, и вместе с этим разблокирует мьютекс).

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

Будто подход Rust не накладывает своих ограничений и не создаёт проблем. Впорос только в том, какие ограничения удобнее, и какие проблемы менее болезнены.

Дайте угадаю, вы опять хотите поведать о том, что в Rust без unsafe нельзя сделать базовые структуры данных, поэтому этот язык не пригоден для серьёзной разработки?
UFO just landed and posted this here
Так всё дело в том, что «правильный» двусвязный список не ложится в концепцию владения, потому что у каждого узла получается два равноправных обладателя.
Но двусвязные списки всё же есть, причём в стандартной библиотеке. Да, под капотом у них unsafe, но публичный интерфейс полностью доступен из safe-подмножества. Можно долго спорить, считается это «честной» реализацией или нет, но тогда давайте не забывать, что где-то в глубине стека вызовов всё равно нет-нет, да и происходит обращение к ядру ОС, которое unsafe просто потому что FFI.
UFO just landed and posted this here
Именно так, полная безопасность недостижима, ведь даже если ПО будет без багов, то всё равно может произойти аппаратный сбой.
Но это не означает, что к безопасности и стабильности не надо стремиться. Те же языки со сборкой мусора (с которых +- начался этот тред) именно поэтому и появились: работать с памятью сложно.
Если под капотом небезопасно, то это не значит, что язык не может выражать только безопасные (без багов памяти) конструкции. К примеру, мы ведь не думаем, как избегать сегфолтов, пиша запросы в SQL? SQL же не считается небезопасным языком только потому что под капотом движок, написанный на C++, и ОС на чёрт знает чём. И то, что на нижнем уровне небезопасные языки, не является причиной того, чтобы и в языке запросов были конструкции для низкоуровневой работы с памятью без проверки корректности.

Ну... В принципе, да имел в виду ту же самую проблему, но только в очередной раз она вылезла мне боком с совершенно другой стороны: попытка сделать простенький скриптовый язык поверх Rust библиотеки снова потребовала писать unsafe-код. Ну, потому что в скриптовом языке тоже нет концепции владения. Получается, что в экосистеме Rust безопасно можно писать только на Rust и в терминах Rust с серьёзными ограничениями на структуры данных и алгоритмы. 🤷🏼‍♂️

Да чтоб я так безошибочно многопоток на Си писал...

Андроид, Хром и Мозилла сходятся на цифре 70. 70% уязвимостей так или иначе вызвано ошибками в работе с памятью.

Во вторых, borrow-checker часто ловит в том числе логические ошибки

В третьих, не borrow-checker-ом единым! У раста очень много других фишек, помогающих писать надёжный код. Option/Result вместо исключений, требование полноты для match, и многое другое — вынуждает программиста думать о всех путях выполнения кода. В том числе, когда что-то идёт не по плану. Возможные ошибки видны как на ладони, и просвечивают через сигнатуры. И они все должны быть обработаны, чтобы программа прошла тайпчек

И, по моему субъективному опыту, писать крупную долгоиграющую систему намного приятнее, когда гарантировано знаешь, где она может посыпаться, а где не может

Велком - что-то про колбасу, наверное, но видел в тексте только про грибы...

UFO just landed and posted this here

https://llvm.org/devmtg/2014-10/Slides/Baker-CustomHardwareStateMachines.pdf

Вроде, есть способы генерировать код для FPGA на llvm, в который и компилируется rust.

Правда, FPGA и PLC разные устройства (кстати, насколько? не в теме), так что придётся немного и железо поменять в лифте, а раз уже меняется, то можно и arm воткнуть. Разумеется с k8s и метриками.

UFO just landed and posted this here

Спасибо, а зачем на RTOS или Linux свой язык лестничной релейной логики. Кажется, можно написать на более привычном C? Я думал, там что-то на уровне отдельных транзисторов, а не SoC. Это не так?

UFO just landed and posted this here

Нет кода - нет багов и зависаний

Всё верно. Поэтому многие разработчики переходят на no-code

Похоже на речь евангелистов типа "Любите говно!"...

С трудом уже сдерживаю желание вычислять по айпи и бить по голове тезаурусом говнопереводчиков, использующих слово «кодировать» („encode“) для перевода слова, означающего «писать код»/«программировать».
UFO just landed and posted this here
Кодировать — это переводить входные данные в закодированные данные. Писать код и программировать — это совершенно другой процесс. Писать на естественном языке — это кодировать, да. Кодировать устную речь при помощи системы письменности. А вот придумывать, что написать — это, как и программирование, совершенно другая задача.
UFO just landed and posted this here

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

А потом узнал, что лифт не работал из-за сбоя программного обеспечения. Тогда он решил попробовать сделать язык программирования, который сводил бы такие ошибки к нулю. Чтобы даже начинающий разработчик мог бы написать код, который не зависал.

Какая элегантная подмена понятий.
Начинающий разработчик пишет программу для здания в 10 этажей (псевдокод):
Пока(этаж<20) повторять
пауза(1 сек);
и она зависает.

О, а мне байку рассказывали, что для лифтов делают управление на плис, так как они доказательно верифицируются.

Ошибки типа переполнения буфера и выхода за пределы массива в языке стали невозможны в принципе.

Всмысле не возможны? Там встроенные проверки и программа падает при попытке записать что-то за границы массива? Как std::vector::at в C++?


Ну так это та же ошибка, только поведение при ней — аварийное завершение программы, а не возможная уязвимость.

Есть get/get_mut, которые возвращают Option. То есть если индекс внутри массива — будет Some(&T) который можно использовать, а если за границами — всего лишь None. Есть даже конструкция if let Some(value) = vec.get(index) {...} как раз для подобных случаев.
Можно обращаться и с помощью квадратных скобок — тогда да, запаникует.

Что будет, если этот Option программист попробует вывести или прибавить к счетчику?


А с записью как?
Ну вот, допустим, вам надо данные крипто-ключа записать в массив. Массив оказался коротким. Вижу 2 варианта: программа запаникует или надо проверять результат, вдруг ошибка вернулся. В любом случае, программа будет работать некорректно. Ну некуда ей этот ключ записывать, а что-то делать с обрезком бессмыслено.


От зависнувшего лифта не помогает. Предотвращает возможность эксплоита — да.

Option нужно распаковать перед использованием, именно поэтому он спасает от ошибок выхода за границу, не вводя панику.
А ещё массивы и ко. знают, какова их ёмкость, так что можно явно проверить перед записью.
Вот вам небольшой пример как это может быть использовано (можете раскомментировать строки 3 и/или 4 если хотите посмотреть поведение для чуть других типов).

Тема лифта не раскрыта совершенно. Как он узнал что сбой был именно из-за ПО, что за баг там был...

У меня есть гипотеза, назовём её bug homeostasis, согласно которой забагованность программного обеспечения не зависит от того, насколько хорошо язык программирования и прочие инструменты защищают от ошибок. Суть в том, что чем более «безопасно» ощущает себя программист, тем более «спустя рукава» он работает, допуская всё тот же процент ошибок в итоге.

Индекс не может выходить за пределы массива? Нет проблем — напишем программу так, чтобы индекс в пределах массива в неверные элементы попадал.

Sign up to leave a comment.