Релиз языка программирования Rust 1.39

Проприетарщина тоже не нужна.

Хиппи, скубенты и красноглазики - это хорошо, но (для большинства) временное состояние. А когда/если человек вырастает из этого возраста, и как-то надо кормить семью, выбирается тот язык, который востребован в индустрии. При этом никто не мешает осилить Rust потом. Если он действительно захавает все ниши С++.

Если бы Linux был бы написан на Rust, то там было бы полно unsafe и подобных багов.

Нет, была бы другая архитектура. Unsafe был бы изолирован в отдельном модуле взаимодействия с железом. Внаружу торчал бы safe API, который вызывающей стороне значительно сложнее вызвать неправильно, а то и вообще невозможно если тщательно продумать типы.

Так сделана стандартная библиотека если что.

Многие не понимают идею сейф. Это не какой-то религиозный принцип чтобы компилятор за тебя нашел все баги.

Это просто дополнительный инструмент, расширение type system, чтобы между модулями, написанными одним или несколькими людьми, коммуницировать больше.

Вполне нормально писать короткие unsafe фрагменты, которые через safe врапер рассказывают остальному миру как ними пользоваться

Процессоры - unsafe, это нельзя обойти. Rust делает unsafe нижний уровень. С делает всё уровни.

а borrow checker это что?

Это часть языка. Синтаксические свойства программы вычислимы. Семантические свойства программы невычислимы (теорема Райса).

Статические анализаторы пытаются определить семантические свойства (отсутствие use after free, скажем) по тексту программы - это задача в общем случае не решается. Статический анализатор может обнаружить какие-то частные случаи ошибок и/или накидать ложноположительных срабатываний.

Borrow checker проверяет синтаксические свойства программы, и если проверка проходит, то это гарантирует некоторые семантические свойства.

Вы решили поиграть в высшее существо, чье мнение божественно? Если вы не используете что-то, это не значит, что другие его не используют. D активно используется на коммерческой основе, но да, не так как go.

У D и Rust довольно разные подход к решению проблем, так что трудно сказать кто лучше. D более продуктивный, Rust предоставляет больше гарантий безопасности.

Синтаксические свойства программы вычислимы. Семантические свойства программы невычислимы (теорема Райса).

гарантирует некоторые семантические свойства

This.

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

1. Утверждаешь голословно что все программисты на Rust думают что Rust исправляет все существующие баги на планете, делает волосы шелковистыми и делает чтобы *** стоял до 100 лет.

2. Говоришь что так как это невозможно, то они идиоты.

Сам придумываешь, сам опровергаешь

D более продуктивный

И вот тут уже нужно померяться репозиториями пакетов.

https://code.dlang.org/ vs https://crates.io/.

Конечно число нам ничего не скажет (хотя разница в 20 раз), но что-то мне подсказывает что живость экосистемы играет важную роль в продуктивности.

Оба конечно не в лиге NPM

Так и представляю название новой книги: «Освой полный курс Теории Вероятностей за 21 день (включает совершенно бесплатный полный курс по стохастическим интегралам, расчитаный на один день)». Картина маслом.

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

С делает всё уровни.

Это не так. На С можно запилить какой угодно уровень safe. Однако далеко не все проверки можно выполнить в compile-time, ну просто по определению. А проверки в рантайме чего-нибудь да стоят. Можно запилить абсолютно безопасное решение на сях, но если оно будет шевелиться как ленивый жук на солнышке, то никого это не устроит. Поэтому пишется reasonable-safe, а там как пойдет. Иногда(редко) не прокатывает. Не прокатило - починяем. Вот и вся незамысловатая стратегия.

Подход «тут читать, тут не читать, а тут рыбу заворачивать», как в расте, на практике ничего не дает. Почему? Потому что главное правило инженерии - прочность конструкции равна прочности самого слабого элемента. Есть unsafe? Безопасность всего кода равна безопасности unsafe фрагмента. Тут можно сказать - дык нам же теперь только об unsafe кусочке надо думать, а не обо всем, что мы наколбасили! Ну так и в сишных прогах, в том же ядре, потенциальные уязвимости не рассыпаны по всему коду гроздьями. Каждый кусок кода делает свою небольшую работу, поэтому локализовать проблемный участок кода это не рокетсайнс.

Что более смузишное: Rust или Go?

Go. Леммингов много по обе стороны баррикад, но у Go на порядки ниже порог вхождения.

Потому что главное правило инженерии - прочность конструкции равна прочности самого слабого элемента. Есть unsafe? Безопасность всего кода равна безопасности unsafe фрагмента.

Полная ерунда. Когда чистил зубы последний раз - час или месяц назад, есть разница. Все на спектре.

Баг можно допустить в каждой точке кода. Если сделать так чтобы целый класс ошибок стал невозможен в 95% кода, то это строго лучше. В каждой из этих функций можно было проморгать указатель или утащить что не нужно в другой поток без сихронизации.

Или ты о просто чустве паранойи? Да, у тебя в 10000 строчках safe кода есть один unsafe, то если быть поехавшим, то ты не будешь спокойно спать, ожидая как этот unsafe прийдет к тебе в постель с ножом. Но это иррациональный страх. Этот кусок был написан с полным осознанием как он работает и в нем соблюдаются нужные инварианты. Когда этот код будут менять, то unsafe будет серьезным тригерром чтобы перепроверить все 5 раз.

Что более смузишное: Rust или Go?

WebAssembly Rust NPM модуль. С враппером в ReasonML и статьей на Medium как вы в миллиард раз ускорили какую-то хрень

Вполне нормально писать короткие unsafe фрагменты, которые через safe врапер рассказывают остальному миру как ними пользоваться

Нарисовал картинку к твоему сообщению

Поэтому пишется reasonable-safe

Ага. И раст позволяет поднять порог этого reasonable-safe в условиях конечных ресурсов.

поэтому локализовать проблемный участок кода это не рокетсайнс.

А добавить проблемный участок кода - как два пальца. Если бы ядро зафиксировали и только правили баги когда-нибудь их бы там не осталось, да.

Ну да, где-то так

Следить за отсутствием инвалидации итераторов

Как и в Rust. Там невалидный итератор вызовет или неправильный результат или панику. А если это оптимизированный контейнер (а unsafe хватает в реализациях), то и креш.

отсутствием выхода за границы в operator []

В Rust это небесплатно, хотя, согласен, в 99% случаев важнее проверить индекс. И в С++ по-хорошему надо бы сделать at и [] паритетными в этом плане, плюс добавить at_unsafe.

отсутствием data races

https://clang.llvm.org/docs/ThreadSafetyAnalysis.html

Который помогает, в том числе, с race conditions (которые в Rust ес-но тоже есть), что гораздо важнее и сложнее отследить.

отсутствием UB.

Rust построен на llvm и от UB в общем и целом также не защищает. Тут уже был топик про это с конкретными примерами.

Таких несложно много набирается.

Да, но при этом С++, при всех его недостатках (во многом связанных с возрастом), все-равно удобнее Rust’a. Многое можно списать на привычку, но Rust объективно слаб и в ООП и в ФП. Зато императивщину на нем писать легко и приятно, тут он отличная замена С (был бы, но нет стандартизированного ABI).

И вот тут уже нужно померяться репозиториями пакетов.

Можно, конечно. Но зачем? Я всего лишь поправил человека в его заблуждении. А так да, у Rust пакетов больше чем у D.

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

Хорошо быть теоретиком.

Ну я к тому что вот это голословно

D более продуктивный

Рассматривается сферическая нестрогость языка на каком-то участке кода. Но продуктивность зависит от экосистемы тоже

Аргумент уровня «спердобейся». Знаем. Не первый день на ЛОРе

Как и в Rust. Там невалидный итератор вызовет или неправильный результат или панику. А если это оптимизированный контейнер (а unsafe хватает в реализациях), то и креш.

Только неправильно написанный итератор, использующий unsafe. Но к случаю for(auto v: vec) { vec.erase(std::remove(vec.begin(), vec.end(), v), vec.end()); } это не имеет отношения.

Использование правильно написанного итератора в расте не может привести к его инвалидации. for v in &vec { vec.remove_item(v); } не скомпилируется, как и все остальные вариации на тему инвалидации итераторов.

Рассматривается сферическая нестрогость языка на каком-то участке кода. Но продуктивность зависит от экосистемы тоже

Замечание справедливое, поэтому уточню - я имел в виду продуктивность при прочих равных. Rust слишком много приносит в жертву безопасности - в этом его сила, и в этом его слабость.

Я думаю слишком много переменных чтобы легко сравнивать. Зависит от задачи, стиля программирования

Rust заставляет указывать ownership. На что в некритичном для производительности коде можно просто в любой непонятной ситуации где передача по ссылке не прокатывает можно заменять на клонирование. Так что не то чтобы это сильно запаривало. С другой стороны сколько стоит время дебага кода на менее строгих языках?

А добавить проблемный участок кода - как два пальца.

Теоретически. Ну, теоретически двухколесный велосипед источник эпических опасностей. Только три колеса спасут человечество!

Нет, четыре! Нет, еще четыре сверху, а вдруг перевернемся? И пеной залить велосипедиста превентивно, на всякий.

А причина падений с велосипеда в чем? В конечном счете в том, что велосипедист едет. Отрубить велосипеду педали по самый руль!

Руль?! Точно, руль! Рулит - значит зарулит не туда! Долой руль!

А теперь на всем оставшемся обрубочке мы попытаемся взлететь. Ну удачи, чо.

Использование правильно написанного итератора в расте не может привести к его инвалидации.

Так-то и в С++ можно написать безопасный итератор. Но т.к. там стандартный подход другой, то принято, в С++ опасно, в Rust нет.

for v in &vec { vec.remove_item(v); } не скомпилируется, как и все остальные вариации на тему инвалидации итераторов.

Не все, вот тут, например, люди не согласны:

https://docs.rs/mdbook/0.3.1/mdbook/book/struct.Book.html#method.for_each_mut

А еще это здорово выкручивает руки, когда хочется за один проход и элементы поудалять и еще что-нибудь поделать. Приходится два раза бегать.

Аргумент уровня «спердобейся».

Уровня «сперва познакомся с предметом обсуждения». Хотя кому это надо - «Знаем. Не первый день на ЛОРе» (с).

Теоретически.

Серьёзно, б? 🙈 https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Linux+Kernel

Проиграл. И че мешает сделать сафе на плюсах? Напоминаю кста что в расте утечка памяти это совсем не ошибка.

Правильный вопрос «что не мешает вечно делать унсафе, там где надо и не надо». Ничего не мешает. Свобода полная

+1, смотрел пару либ для раста, там унсейф на унсейфе, даже там где можно без него. Кривые руки ништо не выпрямит.

В одном из прошлых тредов ананимус приносил D в виде метода map!, принимающего аргументом строку, содержащую код. Прям вот так, в кавычках, код.. В D много такой зашкаливающей безопасности встречается?

Да пффф. https://www.whitesourcesoftware.com/most-secure-programming-languages/

С выводами ознакомься.

https://www.blackhat.com/docs/eu-17/materials/eu-17-Arnaboldi-Exposing-Hidden-Exploitable-Behaviors-In-Programming-Languages-Using-Differential-Fuzzing-wp.pdf

https://www.techrepublic.com/article/five-programming-languages-with-hidden-flaws-vulnerable-to-hackers/

Теоретики.

Кстати не гарантирует что это runtime eval, может все еще компилироваться

Define в сях тоже компилится. Что не делает его менее опасным и нечитабельным

В одном из прошлых тредов ананимус приносил D в виде метода map!, принимающего аргументом строку, содержащую код. Прям вот так, в кавычках, код.. В D много такой зашкаливающей безопасности?

Это точно не опасней вот этого:

https://doc.rust-lang.org/1.5.0/book/compiler-plugins.html

И точно удобнее. Особенно учитывая состояние реализации в Rust.

И? Падаем с одноколёсного велосипеда без сиденья и будем падать, пффф?

В руст нужно специально заморочиться чтоб его сделать. А в плюсцах это как водички попить

Я думаю слишком много переменных чтобы легко сравнивать. Зависит от задачи, стиля программирования

Полностью согласен

Rust заставляет указывать ownership. На что в некритичном для производительности коде можно просто в любой непонятной ситуации где передача по ссылке не прокатывает можно заменять на клонирование. Так что не то чтобы это сильно запаривало. С другой стороны сколько стоит время дебага кода на менее строгих языках?

Использование клонирование это все-таки костыль. Насчет стоимости дебага верный аргумент. Но по своей практике скажу, что все больше и больше приложения носят высокоуровневый характер и их пишут не программисты, а специалисты предметной области. И для них раст не подходит. А человек, владеющий растом, не владеет предметной областью. А человек, владеющий и тем, и тем - дорого стоит и встречается очень редко. И тут получается, что лучше пусть у нас будет приложение, где исправление бага, допущенного «не программистом, а специалистом» стоит дорого, чем вообще не будет приложения. Потому что программист, способный его написать на Расте просто не владеет предметной областью. Я знаю проект, написанный на коленке и через одно место, но который работал и приносил экономический эффект и которые за год работы команда профессиональных программистов не смогла переписать. От слова совсем.

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

для особо одаренных, сравнение велосипедов в лоб

https://thehackernews.com/2015/12/programming-language-security.html

Пилите дальше свои квадратноколесные.

В одном из прошлых тредов ананимус приносил D в виде метода map!, принимающего аргументом строку, содержащую код. Прям вот так, в кавычках, код.. В D много такой зашкаливающей безопасности встречается?

А что там не так с безопасностью-то? Это просто напросто небольшой DSL, ничего критичного для безопасности там нет от слова совсем. Не надо показывать так открыто, что не понимаете о чем речь идет.

Знаю что можно, вопрос был, как часто такое в обычном коде в D? Настолько часто, что это стандартный метод у массива? Довольно странно как мне кажется

The security researchers crawled popular web scripting languages

Хех. Включая язык C/C++

Странно было, что чувак решал рядовую задачу (лямбду) через это. Оттого и вопрос, в Дэ это обычное явление или чувак – затейник?

как часто такое в обычном коде в D?

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

including PHP, Java, JavaScript, Ruby, .NET, C and C++, Microsoft Classic ASP, Android, iOS, and COBOL, scanning hundreds of thousands of applications over the last 18 months.

в той же строке. Формулировки у автора статьи те еще, но к исследованию Veracode это отношения не имеет.

Само исследование тут

https://www.veracode.com/sites/default/files/Resources/Reports/state-of-software-security-focus-on-application-development.pdf?mkt_tok=3RkMMJWWfF9wsRovua3NZKXonjHpfsX96%2B4pUKC0lMI%2F0ER3fOvrPUfGjI4ATctiNa%2BTFAwTG5toziV8R7fMLM160cIQWRjj

А что там не так с безопасностью-то? Это просто напросто небольшой DSL

Краткое описание tcl

А что там не так с безопасностью-то? Это просто напросто небольшой DSL

Краткое описание tcl

Понятно. Классическое «Не читал, но осуждаю». Ну очевидно, что вы не понимаете о чем говорите, но представляете это как будто это что-то ужасное. А там ничего ужасного то и нет в помине.

По факту сходные по производительности языки типа go и D оказались существенно популярнее, потому что меньше заморочек.

популярнее

D

Это шутка?

Ну и Rust быстрее по определению, ибо GC не может быть zero cost.

Лихо вы виляете.

Ну очевидно, что вы не понимаете о чем говорите

Дя. Однако, я помню как на каких-то сишных дефайнах (от гугла) мне удавалось писать код, синтаксически корректный, но делающий не то, что я хотел. И чтобы это выяснить, я через gcc выводил портянки, полученные после препроцессора и вчитывался в них

На лишпе так вообще наворотить такого можно, что патологоанатом потом не разберется

Короче, вижу макросы – сразу подозрительность включается. Думаешь зря это я?