Очередного обсуждения Rust тред

Cargo check актуален скорее потому, что синтаксис настолько сложен, а компилятор настолько придирчив. что написать код сразу безупречно — это «миссия невыполнима».

Это уже передёргивание, я так тоже могу: cargo check актуален скорее потому, что в языке так много проверяется на этапе компиляции, что это всплывают ошибки, которые в другим языке ты бы ловил тестами.

        jmp     .LBB0_1
.LBB0_1:
        xor eax, eax
...........................

во имя сатаны сразу прыгать на следующую инструкцию??? поясните!

Java очень близко подобралась к этой цифре, поскольку у нее даже стандартная либа написана на безопасных коннструкциях

Видимо ты мало читал исходный код стандартной либы. Там всё, что связано с платформой, на C и падать может запросто.

Ещё один момент - чтобы на Rust утекла память, нужно постараться. Чтобы на Java утекла память, стараться не нужно.

Ещё один момент - safe код на Rust удобно использовать в многопотоке. Сколько времени я потратил, читая исходники в Java, пытаясь выяснить, можно ли какой-нибудь DocumentBuilderFactory шарить в тредах безопасно - не счесть.

C/C++ такого деления нет, библиотека и сами программы пишутся на одном и том же языке.

В стандартных библиотеках C/C++ используются built-in функции компиляторов(__builtin_xxx), и кое-что ты просто не можешь реализовать на стандартном С/С++, кое-что будет медленнее.

Но, конечно, можно и самому использовать built-in функции, это да…

Это был порт вот этого примера:

И что он показывает? Ну кроме того, что unsafe - ансейф?

И что он показывает? Ну кроме того, что unsafe - ансейф?

не все об этом знали.

Очередного обсуждения Rust тред (комментарий)

«Невозможно» и «Сложнее» - разные слова.

Забавно, когда поклонники языков без GC посмеиваются над недетерменированностью GC, хотя время выполнения malloc (вручную или нет) тоже недетерменировано

GC вообще никогда не было проблемой. Проблемой было его бездумное использование для чего попало. Если я сделаю хэш-таблицу в виде монолитного объекта-массива, и в этой таблице буду хранить скалярные значения (не ссылки), то стоимость обработки сборщиком мусора такой хэш-таблицы будет околонулевая. Если же я ту же хэш таблицу реализую в виде массива ссылок на объекты, каждый из которых представляет собой ссылку на хэш, ссылку на ключ, и ссылку на значение, то обработка большой таблицы сборщиком мусора будет очень дорогой.

И проблема в жаве возникла именно из-за этого — большое число мелких объектов, по которым очень дорого проходить сборщиком. И эта проблема меньше выражена в JS именно потому, что многие продвинутые контейнеры V8 (у них нет 1-к-1 соответствия среди типов JS) очень легкие в плане сбора мусора, поскольку представляют собой именно скалярные массивы, а не ссылки на ссылки на ссылки. Помимо всего прочего, такой подход еще и ускоряет работу со структурами данных, благодаря чему построенный на ассоциативных массивах с ног до головы язык внезапно по производительности соревнуется с JVM, а памяти жрет стабильно меньше JVM.

Ты кажется не понимаешь, для чего unsafe вообще нужен, если начинаешь искать его в системных вызовах

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

Зелёные грабли лежат посреди луга. Портируем… Красные грабли обставленные флажками лежат посреди луга. Ну? Все видят, что ничего не изменилось?

Ладно бы еще в 90-х годах. А сейчас посмотри на статистику популярности ЯП — никому твоя байтомолотилка не нужна, всем подавай скрипты, в крайнем случае C#/Java.

Не согласен: Nim, Zig, Odin, Beef, Jai - низкоуровневые языки продолжают появляться и вызывают интерес у (некоторой) аудитории. Взлетят ли они? Сомневаюсь, но и раст начинался как эксперименты одного чувака.

Какой смысл смотреть на топ популярности? Swift, который по сути безальтернативен на своей платформе (причём платформе популярной!), даже в десятку TIOBE не попадает. Аналогично с Go, за которым стоит гугл. Оба языка, кстати, без виртуальной машины, хотя и со сборкой мусора. Можно из этого сделать вывод, что раз у них такие результаты, то не стоит даже дёргаться, а можно попробовать найти нишу.

Вообще не понимаю, откуда ты это взял.

Из какой-то темы про хаскель, но может неправильно тебя понял.

Да, считаю, но в качестве цели выбрал питон. «Пробую» уже года два, всю низкоуровщину на Си написал и оттестировал, осталось прилепить питоньи интерфейсы и заценить реакцию сообщества.

Безотносительно того, что я думаю про такую идею: есть смысл «рекламировать» (или скорее информировать о) свою идею пораньше. Не думаешь же ты, что твою славу украдут? Тогда стоит пораньше привлекать людей: может подскажут что-то или даже заинтересуются. Тут главное на критику болезненно не реагировать - она будет в любом случае и разная.

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

Возможно, такой фактор тоже есть. С другой стороны, новичкам работу на расте найти очень сложно.

Решения не были приняты не потому, что не было ресурсов, а потому, что всем было пофиг. Да, компилируется очень медленно — но ничего, подождем, поработаем над другой веткой. А когда компилятор обрастает костылями и оптимизациями, то трудоемкость его разработки начинает быстро расти.

Вероятно, мы о разных проблемах. Я не буду говорить, что медленная компиляция - это ерунда, но всё-таки всё-таки у языка другие приоритеты. Если бы раст (в нынешнем виде) быстро компилировался, но работал бы заметно медленнее, то критики было как бы даже не больше. Кому нужен медленный низкоуровневый и не самый простой язык?.. Можно ли усидеть на обоих стульях? Не уверен. И твой пример с гуглом и питоном меня в этом скорее убеждает.

Ну и я всё-таки не согласен, что эти проблемы не связаны с ресурсами. Да, до 1.0 было легче всё ломать и экспериментировать. Но чем дольше язык был бы нестабильным, тем меньше он был бы нужен - действительно какой-нибудь Nim мог бы перехватить интерес у людей, деньги мозиллы бы кончились и вместо текущей ситуации (когда язык подхватили другие организации) его могли бы просто закопать. Поэтому к 1.0 шли ударными темпами и не без жертв. Например, макросы стабилизировали в кривоватом виде обещая потом macro 2.0. Процедурные макросы так вообще стабилизировали позже и т.д.

во имя сатаны сразу прыгать на следующую инструкцию??? поясните!

Не готов. (:

«Невозможно» и «Сложнее» - разные слова.

Обычно подразумевают «невозможно в [safe] расте», но ок.

Упрекать Раст в неудобстве разработки - это ну очень сомнительный аргумент, он на шаг впереди в плане удобства сборки, генерации документации, стандартизации, да даже удобства разработки компиляторов при условии использования LLVM

Не, у вас в вашем поедании кактусов совсем замылился глаз. Это у C/C++ отвратительная сборка и стандартизация, и на их фоне Раст смотрится довольно неплохо. То, что в C++ модули собираются вводить только вот-вот сейчас, когда в паскале они были уже в 80-х, а неофициальный стандарт по паскалю был уже в 70-х годах.

Я в unsafe коде на Rust потру стэк, используя некорректный указатель

Ну в Си его потри. Вот только в Раст 99% кода у тебя проверяется компилятором, а в Си 0%.

Твой аргумент был:

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

Не может проблема располагаться в C/C++ в каждой строчке. Ты используешь стандартную либу — проблема не в этой строчке. Ты не используешь разыменований указателей — проблема не в этой строчке. А вот найти настоящую строку, которая повредила память, тяжело и в C, и в C++, и в Rust, потому что ты, как правило, не попадешь на ту самую проблемную строку кода сразу, а перечитывать все «немногочисленные» unsafe-ы в миллионе строк кода никто не будет.

Прямо как в Си. К слову, большинство крейтов Раст - биндинги к сишным библиотекам

И в том числе это. Стандартная либа раста — это примерно такая же «сишная библиотека», только немного приукрашенная снажури типизацией.

Очень жаркий тред, но я всё-таки вставлю свои пять копеек.

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

Во-первых, у языка нет явного стандарта как у C или C++. Та спецификация что есть, описывает реализацию одного единственного компилятора. По сути язык это то, что есть в одной референсной реализации. Простой пример - переполнение чисел. Сказано, что если собирать в дебаге, то это приводит к панике, а если в релизе - к wrapping. Но что такое сборка в дебаге или релизе с точки зрения самого языка в терминах абстрактной машины? Такого нет и в мире C/C++ это бы называлось implemetantion defined или undefined behavior. И такого в расте сплошь и рядом. Слишком всё завязано на единственную реализацию компилятора.

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

В-третьих, этот язык невозможно использовать в safety critical приложениях, хоть этот язык и продвигается как решение memory safety проблем. Причина кроется в том, что в таких системах часто необходимо иметь сертифицированный тулчейн. К примеру, я работаю в автомобильной сфере и для того, чтобы использовать тулчейн, важно иметь сертификацию ISO 26262 для него. Аналогично в авиастроительных и аэрокосмических сферах. Если сертификации нет, то нужно вручную соотносить каждую строку кода с скомпилированным машинным кодом и проверять что машинный код корректен. Это такой мазохизм, что никто в здравом уме этим заниматься не будет.

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

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

Упрекать Раст в неудобстве разработки - это ну очень сомнительный аргумент, он на шаг впереди в плане удобства сборки, генерации документации, стандартизации, да даже удобства разработки компиляторов при условии использования LLVM

Не, у вас в вашем поедании кактусов совсем замылился глаз. Это у C/C++ отвратительная сборка и стандартизация, и на их фоне Раст смотрится довольно неплохо. То, что в C++ модули собираются вводить только вот-вот сейчас, когда в паскале они были уже в 80-х, а неофициальный стандарт по паскалю был уже в 70-х годах.

вы как бы говорите одно и тоже, замылился глаз все-таки у вас )

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

Это надо было делать с С++ сразу же. Потому что по итогу он нифига не совместим с Си, сишные функции там дергаются через разноцветные обертки. Точно так же сишные функции может дергать какой-нибудь питон или паскаль.

PS: кстати, я реально не пойму, чем руководствовались люди, которые решили, что С-подобный язык в лице C++ будет реально хорошей идеей. Потому что задним числом-то мы уже видим, что идея была очень плохая.

очень близко подобралась к этой цифре

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

стандартная либа написана на безопасных коннструкциях

хакеры, крякеры, вирмейкеры тихо смеются в сторонке над твоим «100%». Программист на джава сам того не подозревая может крашнуть прогу - JVM дырявая и глючная как решето https://www.securitylab.ru/news/454478.php

JVM дырявая и глючная как решето

Сейчас придёт Биореактор и скажет, что ты лжец, подлец и негодяй.

все дырявое, даже биореактор, такова жизнь.

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

Очень спорное суждение, если учесть, что библиотеки Rust — это, зачастую, тупо обертки над C/C++ либами. А вот найдется ли ресурсов и желания переписывать их на Rust — это второй спорный вопрос. Так-то я не спорю с тем, что C++ менее безопасен, чем Rust. Я лишь спорю с тем, что Rust безупречно безопасен — это не так, он лишь немного более безопасен, чем C++, если в разработке на C++ кодеры надрессированы использовать именно безопасные приемы, даже без вечно стоящего над душой компилятора (но со стоящим над душой сеньором).

Мне не нужно писать unsafe, чтобы использовать макрос println. Поэтому я смогу написать hello world полностью безопасно
У тебя странное представление об unsafe. Если макрос использует в своей реализации unsafe-код, это не значит, что он небезопасен в использовании

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

500 unsafe-ов на 20 тыс строк сорцов, включая комментарии.

И это в ядерном коде. В 40 раз меньше небезопасного кода, чем было бы на C

Еще раз: это только явные описания небезопасных инструкций. Там еще в несколько раз больше неявных, вроде вызовов контейнеров и макросов.

В этом суть unsafe-кода, он вкладывается в макрос или функцию, которые гарантируют его безопасное использование

Пример с рекурсивной инициализацией std::sync::Arc говорит, что стандартная либа не гарантирует безопасное использование себя.

Очень спорное суждение, если учесть, что библиотеки Rust — это, зачастую, тупо обертки над C/C++ либами.

Если это тупо обёртка, то она не нужна. Но чаще всего это не тупо обёртки, а творчески подготовленные обёртки. Которые невозможно использовать неправильно. И такие обёртки уже нужны. Даже без переписывания.

Я лишь спорю с тем, что Rust безупречно безопасен — это не так, он лишь немного более безопасен, чем C++, если в разработке на C++ кодеры надрессированы использовать именно безопасные приемы, даже без вечно стоящего над душой компилятора (но со стоящим над душой сеньором).

Безупречного ничего нет, даже кеши в процессоре текут. Но я уверен, что Rust ощутимо безопасней при сравнимом уровне разработчиков и что Rust намного безопасней при, скажем так, среднем уровне разработчиков.

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

Он определённо сделает такой код более безопасным. Например он может гарантировать, что вызывающий этот код не передаст в него неправильный указатель (без использования unsafe). Rust позволяет спроектировать API, которое будет гарантировать правильный порядок вызова функций, например то, что функции работы с объектом не будут вызваны после какого-нибудь my_object_dealloc.

Это я сравниваю с C, на C++ такое в принципе тоже можно сделать. Но гарантировать C++ ничего не может, нет в нём формально определённого безопасного подмножества.

Ты отрицаешь возможность написать безопасную обёртку над ансейфом или тут какая-то более глубокая мысль?

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

И проблема Раста здесь в том, что без unsafe на нем можно написать чуть более, чем ничего. То есть, если ты что-то пишешь на расте — ты будешь использовать unsafe, хочешь ли ты этого или нет, это не какая-то темная сторона, которую никто не видит, это абсолютно рядовая конструкция. Другими словами, на самом деле у тебя не безопасный раст с unsafe конструкциями — на самом деле у тебя unsafe конструкции (в том числе стандартная библиотека), дополненные безопасными чистыми блоками. И даже в этих условно безопасных чистых блоках есть уйму возможностей выстрелить себе в ногу каким-нибудь доступом по некорректному индексу.

Я хочу особо подчеркнуть последний пункт. При разработке раста вообще не было требования стабильности работы — при малейшей проблеме программа на расте немедленно падает. Разработка Раста велась именно для устранения UB. То есть, если программа на C++ с ошибкой будет валится в 20% случаев, то программа на Rust завалится в 100% случаев — это смысл создания раста, это его основная фича, с которой он продается.

Это уже передёргивание, я так тоже могу: cargo check актуален скорее потому, что в языке так много проверяется на этапе компиляции, что это всплывают ошибки, которые в другим языке ты бы ловил тестами

Да. Пока ты будешь дергать десять раз cargo check — я уже десять раз скомпилирую и протестирую свою сишку. И это еще большой вопрос, кто из нас быстрее справится. Впрочем, я не буду спорить с тем, что в долгосрочной перспективе сишка будет проблематичнее. А вот с C++ ситуация уже не так очевидна, и вполне может оказаться, что кресты даже в долгосрочной перспективе выгоднее.

Видимо ты мало читал исходный код стандартной либы. Там всё, что связано с платформой, на C и падать может запросто

Блин, ну конечно же системные вызовы ты на жаве не напишешь.

Ещё один момент - чтобы на Rust утекла память, нужно постараться. Чтобы на Java утекла память, стараться не нужно

Ты про веселости GC в Java? Если в расте играться с Arc, то можно легко подобный результат получить.

Ещё один момент - safe код на Rust удобно использовать в многопотоке. Сколько времени я потратил, читая исходники в Java, пытаясь выяснить, можно ли какой-нибудь DocumentBuilderFactory шарить в тредах безопасно - не счесть

Аргумент засчитан. Правда, аналогичные гарантии могут дать любые библиотеки и/или языки, построенные с ног до головы на персистентных/неизменяемых структурах данных. Если же тебе нужно работать в многопотоке с разделяемыми изменяемыми данными, то тебя уже никакой Rust не спасет, потому что по его понятиям это строго unsafe операции. То есть, да, Rust помогает, но в ограниченной сфере.

В стандартных библиотеках C/C++ используются built-in функции компиляторов(__builtin_xxx), и кое-что ты просто не можешь реализовать на стандартном С/С++, кое-что будет медленнее

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

Если же тебе нужно работать в многопотоке с разделяемыми изменяемыми данными, то тебя уже никакой Rust не спасет, потому что по его понятиям это строго unsafe операции.

Ещё раз. Раст запрещает несинхронизированное обращение к шареной памяти в safe коде. Несинхронизированное обращение - это data races. Иметь data races в программе, и гарантировать, что она будет работать без проблем - это уровень жонглирования кинжалами с прыжками через горящие обручи. См. например https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf

Да, если хотите жонглировать кинжалами, вместо того, чтобы синхронизировать доступ - пишите unsafe.

у языка нет явного стандарта C или C++

Как человек писавший парсер для С, я тебе скажу что на таком простом этапе как «лексический анализ» разные компиляторы дают разный результат - хотя в стандарте черным по белому написано что и как должно обрабатываться.

что такое сборка в дебаге или релизе

Это никак не относиться к дебаг/релиз сборке. Гейзенбаг никто не отменял! даже если ты хоть Lua скрипты будешь дебажить в тулзовинах не факт что ты получишь тот же результат. Любая отладка, любая профилировка, любой мониторинг вносит коррективы в выполнение программы.

на некоторых платформах, которые раст не поддерживает.

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

этот язык невозможно использовать в safety critical

а скажи какие новые технологии или языки можно использовать в этом бюрократическом болоте?

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

Агресивный маркетинг разве что от бомбящих жоп на лоре.

предложить начать переводить его на раст.

Расскажи это любителям писать свою ОС на JS и запускать ее внутри браузера.

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

был у nVidia с ее рейтресингом, которая продавала школоте 30 летние технологии RT под видом «нового слова в IT», для того чтобы в ЗД шутерах в калюжах появлялись отражения, которые и были до этого и специально отключала их в обычных рендерах в рекламных роликах. И каждый «фанбой» считал своим долгом орать в каментах на любых форумах, особенно под роликами ютуб «а давайте любимую ноунейм игру на RTX запустим» чтобы посмотреть как несчастный рендеринг простого полигона будет греть видуху до красна. Да такой маркетинг засрали просто все информационное пространство.

Хомячизм заиграл новыми красками, особенно на фоне пандемии.

Ты про веселости GC в Java?

Я про то, что ничего не мешает где-нибудь в объекте оставить какой-нибудь бесконечно растущий кеш. С Rust вроде бы с этим намного сложней неявно сделать.

Если же тебе нужно работать в многопотоке с разделяемыми изменяемыми данными, то тебя уже никакой Rust не спасет, потому что по его понятиям это строго unsafe операции. То есть, да, Rust помогает, но в ограниченной сфере.

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

Nim, Zig, Odin, Beef, Jai - низкоуровневые языки продолжают появляться и вызывают интерес у (некоторой) аудитории

У аудитории из трех человек? Nim — это все-таки не совсем низкоуровневый язык, это скорее диалект питона, вроде Julia или Numba, которые в очередной раз пытаются исправить фундаментальные ошибки архитектуры питона (архитектуры, которой у питона нет).

Какой смысл смотреть на топ популярности? Swift, который по сути безальтернативен на своей платформе (причём платформе популярной!), даже в десятку TIOBE не попадает

не нравится TIOBE — ради бога, вот тебе stackoverflow:

https://insights.stackoverflow.com/survey/2020#technology-programming-scripti...

Вот тебе и свифт, и Go рядом с котлином, и VBA, и Dart, и Scala. И даже Julia. В вот Nim-а нету.

Вообще не понимаю, откуда ты это взял.

Из какой-то темы про хаскель, но может неправильно тебя понял

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

С другой стороны, новичкам работу на расте найти очень сложно

Я боюсь, что работу на расте вообще непросто найти.

Кому нужен медленный низкоуровневый и не самый простой язык?.. Можно ли усидеть на обоих стульях? Не уверен. И твой пример с гуглом и питоном меня в этом скорее убеждает

Julia, Numba — вот тебе быстрые питоноподобные языки. Но это не питон, тем не менее.

Ну и я всё-таки не согласен, что эти проблемы не связаны с ресурсами. Да, до 1.0 было легче всё ломать и экспериментировать. Но чем дольше язык был бы нестабильным, тем меньше он был бы нужен - действительно какой-нибудь Nim мог бы перехватить интерес у людей, деньги мозиллы бы кончились и вместо текущей ситуации (когда язык подхватили другие организации) его могли бы просто закопать

Недавно был тред про финансовые показатели мозиллы: ЗП манагеров растут, доля Firefox на рынке падает — вот тебе и «ресурсы». Типовое такое разложение компании по принципу эффективных менеджеров. А могли бы раст и закопать — невелика беда. Толку нам, простым программистам, с еще одного ненужного языка? Rust ведь нужен корпорациям, это организационный инструмент для контроля за индусами, это не инструмент для любви с компьютером.

Безотносительно того, что я думаю про такую идею: есть смысл «рекламировать» (или скорее информировать о) свою идею пораньше. Не думаешь же ты, что твою славу украдут?

Мне ведьмак тоже делал замечание по этому поводу. Я уже две статьи нахерячил. Реакция чуть более чем никакая — в итоге возникают вопросы «когда релиз», «дай потестить», а потестить-то и нечего. Ну типа я мог бы начать писать всякие там ТЗ с конкретикой, но на фоне почти полного отсутствия подобных реализаций затраты на принятие решений и их тестирование настолько велики, что реализацию я уже и сам могу сделать «на сдачу». К тому же, не так много людей пишет код в том параноидальном стиле, в котором я пишу (2 assert-а на десять строчек кода), и который совершенно необходим для того, чтобы иметь необходимый минимум для отладки, без которого сложность тестирования и отладки возрастает до небес.

Также стоит понимать, что эти два года разработка ведется в режиме «один день в неделю» — иначе бы я менее чем за год закончил тот же объем работы, там его не так много (порядка 10 к строк), это все-таки больше прототип, чем что-то production-ready.

Сам язык достаточно интересный, с определёнными инновациями, но всё что вокруг него происходит наталкивает на мысль, что он ещё не готов к продакшену. Вернее, не к всякому продакшену

Тут уже в треде есть тезисы, намекающие, что он никогда не будет «готов ко всякому продакшену».

Был реальный пример, как разработчики одной библиотеке на питоне перешли с одной зависимости, написанной на C, на реализацию на расте и это поломало работоспособность этой библиотеки на некоторых платформах, которые раст не поддерживает

Во-во, боже упаси меня писать под питон что-то на расте. Потом хрен соберешь.

Упрекать Раст в неудобстве разработки - это ну очень сомнительный аргумент, он на шаг впереди в плане удобства сборки, генерации документации, стандартизации, да даже удобства разработки компиляторов при условии использования LLVM

Это у C/C++ отвратительная сборка и стандартизация, и на их фоне Раст смотрится довольно неплохо. То, что в C++ модули собираются вводить только вот-вот сейчас, когда в паскале они были уже в 80-х, а неофициальный стандарт по паскалю был уже в 70-х годах.

вы как бы говорите одно и тоже, замылился глаз все-таки у вас

Не одно и то же. Он подразумевает, что у Rust лучше сборка и стандартизация чем у всего на свете или почти всего. Я же возражаю, что проблема эта актуальна только для C/C++, и то для крестов уже активно продвигается ее решение, что потенциально лишит Rust еще одного преимущества над своим главным конкурентом (C++).

у языка нет явного стандарта C или C++

Как человек писавший парсер для С, я тебе скажу что на таком простом этапе как «лексический анализ» разные компиляторы дают разный результат - хотя в стандарте черным по белому написано что и как должно обрабатываться.

Если есть стандарт языка, где прописано одно, а компилятор делает другое, то это баг компилятора.

что такое сборка в дебаге или релизе

Это никак не относиться к дебаг/релиз сборке. Гейзенбаг никто не отменял! даже если ты хоть Lua скрипты будешь дебажить в тулзовинах не факт что ты получишь тот же результат. Любая отладка, любая профилировка, любой мониторинг вносит коррективы в выполнение программы.

Мой пример взят с официального растовского RFC https://rust-lang.github.io/rfcs/0560-integer-overflow.html . Мой посыл в том, что такое определение - это по сути документация компилятора, а не языка, что попадает под определение implementation defined behavior. Должна ли альтернативная реализация компилятора повторять это? Должны ли быть определения дебажной или релизной сборки в описание языка? Для сравнения стандарт C++ написан в терминах абстрактной машины и там нет такого, что в дебаге получишь одно, а в релизе - другое.

на некоторых платформах, которые раст не поддерживает.

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

Как ты собираешься выполнять программу на расте если компилятор не умеет компилировать её под эту платформу?

этот язык невозможно использовать в safety critical

а скажи какие новые технологии или языки можно использовать в этом бюрократическом болоте?

Очевидно, C/C++ с сертифицированным компилятором (не GCC и не Clang).

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

Агресивный маркетинг разве что от бомбящих жоп на лоре.

Не только тут, но и на LKML. Был даже такой мем Rewrite-it-in-Rust несколько лет назад. https://transitiontech.ca/random/RIIR

предложить начать переводить его на раст.

Расскажи это любителям писать свою ОС на JS и запускать ее внутри браузера.

Фанбои есть везде, не только в расте.

Я сам полюбил Раст но не за рекламу его безопасности, а за то что это осовремененный Си

Так я его сам люблю за это. Это как женщина, у которой зачетный попец, и промежуток, и 90-60-90, и характер приятный, но ЛИЦО СТРАШНОЕ КАК СМЕРТЬ. И что с ней делать — непонятно.

хакеры, крякеры, вирмейкеры тихо смеются в сторонке над твоим «100%». Программист на джава сам того не подозревая может крашнуть прогу - JVM дырявая и глючная как решето

Ну я потому и пишу, что «не 100%, но близко». Другие решения подобных масштабов имеют намного больше уязвимостей.

Он определённо сделает такой код более безопасным. Например он может гарантировать, что вызывающий этот код не передаст в него неправильный указатель (без использования unsafe). Rust позволяет спроектировать API, которое будет гарантировать правильный порядок вызова функций, например то, что функции работы с объектом не будут вызваны после какого-нибудь my_object_dealloc

Мой опыт разработки на Си и делфи говорит, что есть такие мозговыносящие требования по вызовам интерфейсов, что даже никакие правила раста не спасут. Например, нельзя передавать определенные параметры или вызывать определенные функции в некоторых режимах работы, потому что либа баганутая и посыпется. И конкретно в этом плане Rust дает не больше гарантий, чем C++. То есть, опять же, стабильность раста определяется стабильностью unsafe кода.

Да, если хотите жонглировать кинжалами, вместо того, чтобы синхронизировать доступ - пишите unsafe

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

Давайте назовем тред: лучше ли Rust, чем C++?

этот язык невозможно использовать в safety critical

а скажи какие новые технологии или языки можно использовать в этом бюрократическом болоте?

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

был у nVidia с ее рейтресингом, которая продавала школоте 30 летние технологии RT под видом «нового слова в IT», для того чтобы в ЗД шутерах в калюжах появлялись отражения, которые и были до этого и специально отключала их в обычных рендерах в рекламных роликах

Ну вот где ты был, когда шли RT-срачи? Если быть точным, то все-таки в рекламных роликах Nvidia использовала игры, в которых этих отражений еще не было, потому что игры разрабатывались где-то в начале нулевых годов или вообще в конце 90-х. Естественно, более современная графика уже неотличима от RT, при том что RT требует в разы больше ресурсов.

этот язык невозможно использовать в safety critical

а скажи какие новые технологии или языки можно использовать в этом бюрократическом болоте?

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

Это всё вытекает из того, что разработчик имеет персональную ответственность перед возможными багами и может сесть в тюрьму из-за них. Поэтому процессы такие сложные, чтобы по возможности максимально исключить человеческий фактор. Tesla не исключение и следует тем же правилам. Иначе она не смогла бы продавать свои машины на рынке. Справедливости ради, не всё в машине является safety critical, а только, как правило, достаточно небольшая часть в определённых системах. Во всех других местах системы процессы гораздо мягче.

Агресивный маркетинг разве что от бомбящих жоп на лоре.

Так-то даже в словари добавили новое слово: RIIR из-за частого употребления

RIIR = Rewrite It in Rust

https://acronyms.thefreedictionary.com/RIIR

А вот слова RIIC нет(rewrite it in C), почему-то…

Но конечно, во всём лоровцы виноваты, нет маркетинга :)

Был даже такой мем Rewrite-it-in-Rust несколько лет назад. https://transitiontech.ca/random/RIIR

P.S. Только сейчас дочитал до этого поста, уже вспомнили. Ну ок. Ссылка другая у меня, оставлю пост…

Я про то, что ничего не мешает где-нибудь в объекте оставить какой-нибудь бесконечно растущий кеш. С Rust вроде бы с этим намного сложней неявно сделать

«Сложнее» только потому, что в Rust что угодно сложнее сделать. В остальном Rust никак не ограничивает возможности программиста по бесконечному выделению памяти. Блин, да у меня сейчас под рукой проект SPA на JS, который «программисты» умудрились завалить через неограниченное выделение памяти — были бы криворукие индусы, а язык уже не так важен.

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

Да. Изменяемые ячейки данных — это оптимизация со времен ЭВМ с 4 килобайтами оперативной памяти. Но проблема в том, что нынешние ЭВМ с 64 ГБ памяти работают почти по тем же принципам, что и те с 4 кБ. То есть, машина Тьюринга. Если же ты строишь на базе этой машины новую абстракцию, более подходящую для многопотока, то у этой абстракции есть цена в виде производительности. А если ты готов эту цену платить, то внезапно выясняется, что можно писать на Java, или на Erlang, или на Go — и Rust уже не нужен.

Если есть стандарт языка, где прописано одно, а компилятор делает другое, то это баг компилятора

Предлагаю тебе на досуге почитать, например, стандарт Си. Весь стандарт написан вокруг от понятия «абстрактный вычислитель», однако, сама работа абстрактного вычислителя нигде не конкретизирована. То есть, как хочешь, так и интерпретируешь стандарт. Чем активно пользуются упоротые писаки GCC.

Для сравнения стандарт C++ написан в терминах абстрактной машины и там нет такого, что в дебаге получишь одно, а в релизе - другое

Да, вместо этого в C++ ты получишь одно конкретное UB/IDB.

Очевидно, C/C++ с сертифицированным компилятором (не GCC и не Clang)

Эх, жалко, что не кобол.

Не только тут, но и на LKML. Был даже такой мем Rewrite-it-in-Rust несколько лет назад. https://transitiontech.ca/random/RIIR

У меня возникает подозрение, что Mozilla перерождается в клоунско-маркетинговую контору.

Это всё вытекает из того, что разработчик имеет персональную ответственность перед возможными багами и может сесть в тюрьму из-за них. Поэтому процессы такие сложные, чтобы по возможности максимально исключить человеческий фактор

Я понимаю это, а также я понимаю то, что Boeing 737 Max прошел через все эти бюрократические формальности, что не помешало двум самолетам успешно разбиться. То есть, вся эта бюрократия нужна для того, чтобы снять ответственность, мол «мы всё прошли, всё выполнили — мы не виноваты», а не для того, чтобы спроектировать надежную систему. Иначе бы никто никогда не писал «надежную» систему на языке Си, потому что надежность и Си — это несовместимые понятия.

Короче говоря, это бессмысленная и беспощадная бюрократия, она является своей собственной проблемой, не имеющей отношения к свойством языка и компилятора Rust.

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

Каких конкретно инструментов вам не хватает для реализации, скажем Software Transaction Memory из упоминавшейся Clojure?

Давайте назовем тред: лучше ли Rust, чем C++?

Ок, какие упоминавшиеся выше инструменты есть в С++, которых не хватает в расте?

И как вы собирались заставить программиста на С++ не шарить ссылки/shared_ptr между потоками без использования синхронизации для доступа к данным?

Если есть стандарт языка, где прописано одно, а компилятор делает другое, то это баг компилятора

Предлагаю тебе на досуге почитать, например, стандарт Си. Весь стандарт написан вокруг от понятия «абстрактный вычислитель», однако, сама работа абстрактного вычислителя нигде не конкретизирована. То есть, как хочешь, так и интерпретируешь стандарт. Чем активно пользуются упоротые писаки GCC.

Читаю регулярно и потому, знаю, что компилятор имеет право трактовать его по своему только в местах, помеченных как implementation defined behavior, undefined behavior, ill-formed program и т.д. Если стандарт явно описывает поведение, но компилятор делает иначе, то это баг компилятора. Другое дело, что они будут делать с этим багом. Стандарт не имеет механизмов принуждения для компилятора, чтобы фиксить эти баги.

Для сравнения стандарт C++ написан в терминах абстрактной машины и там нет такого, что в дебаге получишь одно, а в релизе - другое

Да, вместо этого в C++ ты получишь одно конкретное UB/IDB.

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

Каких конкретно инструментов вам не хватает для реализации, скажем Software Transaction Memory из упоминавшейся Clojure?

Для реализации STM нужны многоверсионные (персистентные) структуры данных и откат изменений транзакции. В принципе, персистентные структуры данных в расте можно реализовать, а вот с откатом транзакций будет посложнее.

Ок, какие упоминавшиеся выше инструменты есть в С++, которых не хватает в расте?

Одинаково, что там, что там.

И как вы собирались заставить программиста на С++ не шарить ссылки между потоками?

Как ты собрался заставить программиста на Rust не шарить ссылки между потоками? Опять же, через проверку кода сеньором, который убедится, что джун не натыкал unsafe-ов. Да. в крестах аналогичный процесс выглядит сложнее. Опять же, мы приходим к тому, что разница между C++ и Rust чисто организационная — для хорошо мотивированного грамотно писать код программиста разница будет невелика.

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

Как ты собираешься выполнять программу на расте если компилятор не умеет компилировать её под эту платформу?

Даже если и мог компилировать. Какой смысл использовать библиотеки раста которые еще сырые очень. Что ты хочешь от языка который начал о себе заявлять в 2016 году???

Что это за платформа такая что LLVM ее не компиляет, признавайся! Пруфы в студию.

не GCC и не Clang Если есть стандарт языка Очевидно, C/C++ с сертифицированным компилятором ().

Который наверняка не скомпилирует этот самый участок как надо. В итоге весь зоопарк софта который проходит спокойно GCC c его педантик режимом.

мы снова возрвращаемся к твоим «то это баг компилятора». пруфы сертифицированного компилятора.

Был даже такой мем Rewrite-it-in-Rust несколько лет назад.

Эти ресурсы читает полтора человек. Давай я тебе приведу бегло пример маркетинга языка - Apple с их Swift, которые они тулят и навязывают на свою платформу, и везде всякие учебные заведения засирают своими буклетами. А в итоге их язычки никому нафиг не нужны за пределами iOS. Это язык одной платформы.

Вообще, Apple это образец лютого бешеного маниакального шабаша маркетологов.

Как ты собрался заставить программиста на Rust не шарить ссылки между потоками?

Для этого в расте есть Send и Sync. Попытка расшарить между потоками мутабельные данные (ссылками или Arс’ами) без синхронизации даст ошибку компиляции. Третий раз пишу, если что.

А unsafe можно даже не проверять руками. Есть #[deny(unsafe_code)]

Желаете ещё какие-нибудь инструменты по проверке наличия отсутствия data races?

Читаю регулярно и потому, знаю, что компилятор имеет право трактовать его по своему только в местах, помеченных как implementation defined behavior, undefined behavior, ill-formed program и т.д. Если стандарт явно описывает поведение, но компилятор делает иначе, то это баг компилятора

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

Аналогичная ситуация, например, в законодательствах, которые порой читаешь, и задаешься вопросом «это на каком языке вообще написано?». Там целые профессии построены вокруг интерпретации этого языка.

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

Определенное поведение для чисел с фиксированным размером, вроде uint32_t. Для всех остальных, вроде uint_least32_t и тем более unsigned char, получаем implementation-defined, потому что степень двойки неизвестна. Это уже не говоря про веселости приведений типов, которые могут еще и привести нас к ситуации, когда мы вообще не знаем конкретного типа. Например:

unsigned long a = 54321;
unsigned short b = 12345;
uint c = (unsigned char)(a + b);

Я понимаю, что это ССЗБ, но речь тут про якобы однозначность трактовки стандарта.

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

Очень помогает то, что авторов компилятора, которые понимают эту машину сильно по-своему, программисты пошлют в пешее эротическое.

мы снова возрвращаемся к твоим «то это баг компилятора». пруфы сертифицированного компилятора

Сертифицированный компилятор нужен для embedded контроллера, который может и вовсе не поддерживаться GCC. Просто потому, что этот контроллер производит одна компания в мире на одном заводе.