По-умолчанию? Замечательно. Плюсы движутся в правильном направлении, но обратная совместимость не позволит им многого сделать.

Нет, не проверяет.

Проверяют методы *::at(size_t), не проверяют доступы по subscript operator (*::operator[]).

https://en.cppreference.com/w/cpp/container/array/operator_at

https://en.cppreference.com/w/cpp/container/array/at

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

Например математика может вызывать переполнение и можно было после каждой операции возвращать Result, иначе unsafe. Все как ты сказал. Но решили так

Не, на выбор. Так же есть методы которые не проверяют.

Прикинь, в 2021 году время работы программиста на порядки дороже времени работы компьютера.

А если компьютер не один?) Например если это база данных которой пользуется весь мир.

проблемы с безопасностью доступа к памяти

Проблемы с безопасностью доступа к памяти не имеют непосредственного отношения к переполнению и некорректным кастам. Даже если рассматривать эту проблему исключительно в контексте доступа по переполнившемуся индексу, индекс может переполняться в safe rust, и потом оказаться использованным без проверки в unsafe контексте.

потом оказаться использованным без проверки в unsafe контексте.

Да, поэтому я написал, цитирую, «В safe расте не создаёт», а не «в расте не создаёт».

У Rust оно хуже всех. Даже C++ быстрее. Это сказывается на общей скорости разработки потому что надо непрерывно тестировать что написано.

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

Ну и кстати https://habr.com/ru/company/alconost/blog/168449/ отличный пример того сколько может стоить 1 лишняя секунда работы компьютера

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

А падение из safe rust в корку по floating point exception без раскрутки стека это безопасно?

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

С учётом массового использования шаблонов в Расте там от малейшего изменения придётся весь проект перекомпилировать.

Исправлено несколько версий назад.

Это же классическая архитектурная задачка, количество зависимостей от неустойчивых компонентов нужно сводить к минимуму.

https://postimg.cc/kB8TFJKM

Приведите ссылку, интересно почитать.

Rust 1.45 июль 2020 года. https://github.com/rust-lang/rust/pull/71269/

у меня rustc компилился и того дольше, часа 3-4 (на рязани 5 3500U + ~6гб озу), в один момент снес и заменил rustc-bin, над еще попробовать выпилить из системы его полностью

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

Для того, чтобы было иначе нужно, чтобы компиляторы много больше умели чем анализ лексики

Такие компиляторы есть, если чо, на них можно доказать программно корректность логики. Это тоже сложно, как и писать на расте, но хотя бы имеет практический смысл, в отличие от тех «гарантий,» которые предоставляет раст. Я писал, что «вижу перед собой собрание манагеров-лезбух из мозилы, как они обсуждают будущее проекта и разрабатывают для него фичи. Мол: никто до сих пор не делал безопасный язык, мы станем первыми разработчиками абсолютно безопасного языка, это убойная фича для маркетинга, мы завоюем мир. И в итоге они фокусируются на идее безопасности, по пути упуская вообще всё остальное, проходя по всем возможным граблям», но сейчас я начинаю осознавать, что увидел не всё, ведь они не просто пожертвовали всем ради «безопасности», они пожертвовали всем, и даже надежностью выполнения, ради отсутствия UB и ради сохранения высокой производительности выполнения, как у C/C++. И получили абсурдный инструмент, который почти никому не нужен.

Rust компилирует сам себя почти час.

Там ещё LLVM компилируется. Вроде полтора миллиона строк.

Сказал человек, который говном исходит в каждом треде про Раст. Вас тут таких человек 10, но вы генерируете процентов 80 растотредов.

Зачем учить особенности safe, unsafe и Си? Можно учить две сущности вместо трёх. Если только боязнь хейтеров, которые будут говорить, что 80% растовских проектов на Си написаны. Зато ведь растовская часть будет абсолютно безопасна

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

А в расте, вообще-то, можно написать почти всё то же, что и в Си. Но в расте еще и приятные типы данных, даже если ты будешь тупо писать перед каждой функцией unsafe — это примерно то, каким был язык до того, как утонул в менеджерско-тоталитарном болоте:

https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-06-2013-04-03

«&mut is now unaliasable»

То есть, вплоть до 2013 года, это был язык программистов. Но, по мере роста толерантности и повышения дневной дозы мета, у ответственных менеджеров развилась паранойя, и они решили обложить язык всеми возможными и некоторыми невозможными формальными ограничениями «чтобы менты от нас отстали», в итоге получив всем нам знакомые ёлочки из Arc<<Mutex<Vec<T>>> на каждый чих с замечательным интерфейсом вроде Arc::get_mut_unchecked(&mut five).as_mut_ptr().write(5) для присвоения значения.

Просто поразительно, насколько манагеры умеют плодить формальности и просто лишние сущности, и насколько не видят в этом проблемы. «Фич» же стало «больше», правильно? Значит, проект развивается.

Не, по такому пути пойдешь, получится Coq/Agda, а они 1) уже есть 2) никому на этой планетке нафиг не всрались

При чем тут Coq/Agda, если сиборгиум предлагает unsafe язык? Хорошую идею предлагает, Rust примерно таким и был когда-то.

Сказал человек, который говном исходит в каждом треде про Раст

Вообще нет.

В проекте на Раст 20 строк с unsafe, то есть, если писать идиоматичный код, в проекте будет 20 или чуть больше строк, которые могут вызвать ошибки, не проверяемые на стадии компиляции. В Си-версии проекта таких строк будет 10к. Ну хорошо, несколько меньше, опустим комментарии. Но ты же не будешь спорить, что шанс поймать ошибку в 0.2% кода и шанс поймать ошибку в почти 100% кода - это разные ситуации?

Ты совершенно забываешь, что safe код — это только отсутствие UB. Ошибка может быть в коде на расте в любой строке, как и на Си, разница лишь в том, что в Си ошибка может дать UB, а в расте она даст панику/дедлок/некорректный результат.

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

Так будет если мы в каждой строчке используем адресную арифметику

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

Ок, не ты, так твои дружки. Вон, они уже 7 страниц навоняли и останавливаться не собираются. Казалось бы, ну пусть каждый пишет на чём ему удобно, время покажет, кто более живучий. Но нет, надо убедить всех (и себя), что «дрист» загнётся в муках, что он ничего не решает и абсолютно бесполезен. Аргументов особенно нет, но это ничего, задним числом как-нибудь натянем сову на глобус.

Придерживаясь достаточно краткого набора правил, ошибки работы с памятью в С легко избежать

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

Ошибка может быть в коде на расте в любой строке, как и на Си, разница лишь в том, что в Си ошибка может дать UB, а в расте она даст панику/дедлок/некорректный результат.

Да, если не обрабатывать ошибки и вызывать unwrap в каждой строчке. В std любая функция, которая может вызвать некорректный результат, возвращает Option или Result. А сторонние библиотеки в принципе гарантий дать не могут. И то, откровенный шлак на crates не берут, а анализом кода занимается целая команда.

Шанс, понимаешь, шанс! Шанс поймать ошибку в Раст во много раз меньше. Да, он тоже есть, но он во много раз меньше. Не надо шланговать и игнорировать это.

Я за Вирта

«Долой жирные программы!» — вот лозунг для избавления от ненужностей.

В настоящий момент в Open Source громоздкие и ненужные срества сборки, дублирующие существующие, это LLVM и Rust. Оба проекта очень энергозатратны в плане компиляции и сборки, а результат компиляции ими не демонстрируют сколь-нибудь выдающихся характеристик. Это программы-паразиты, сремящиеся собой окружить другие подсистемы и за счёт них развиваться и жирнеть.

То есть, вплоть до 2013 года, это был язык программистов.

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

Есть дырявый каст as (что там, кстати, про safety рассказывалось?) и небезопасный transmute

Ну «as» — это превращения между подобными типами, в основном небезопасными или целочисленными. В сихе и частенько в C++ подобные превращения и вовсе без кастов делаются.

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

Какие аналоги, какими безопасными методами, конкретику в студию

Я боюсь, что это создание руками служебных трейтов, возвращающих результат каста. Аналога dynamic_cast в расте просто нету — там какая-то заморочка с таблицами виртуальных методов, которые различны для Box<T1>, Box<T2>, и Box<T1 + T2> при том, что trait T2: T1, то есть, T2 является производным от T1.

Какое отношение слайсы имеют к адресной арифметике?

Слайсы решают проблему адресной арифметики для массивов. Правда, не решают ее для сложных структур вроде комбинаций массив + struct + union.

Нет наследования – нечего решать. Безопасность превыше всего

Справедливости ради, наследование — зло. А композиция — добро и любовь.

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

В десятый раз повторяю: Rust НИКАК НЕ ЗАЩИЩАЕТ от алгоритмических ошибок или отказа программы в результате некорректной операции, вроде выхода за границы массива или числа. Rust защищает от уязвимостей удаленного выполнения кода, и только. Даже от DOS-атаки не защищает.

ты можешь 99% времени писать, не заботясь о переполнениях, освобождениях памяти

Потому что 99% времени ты будешь заморочен ублажением borrow checker-а.

убогих строках

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

А в расте есть что-нибудь похожее на Qt? Чтобы я, не особо вникая в устройство фреймворка и параллельно читая книжку, смог за неделю родить приличное GUI приложение?

GUI — это unsafe mutable shared data, потому его использование недопустимо в идеоматичном коде на Rust.

Это как на мерседесе ездить по России, машина хорошая, спору нет, но если до ближайшего сервиса 200 км, она не нужна

Это ты еще ленд роверы не пробовал, на которых, как на УАЗ-е, лучше с трассы не съезжать, но УАЗ можно хотя бы отремонтировать не выходя из кабины.

В сях и плюсах это создаёт проблемы с безопасностью доступа к памяти из-за непроверяемого по умолчанию индекса при доступе к массивам и это, гм, фича (развязанные руки, простреленные ноги и т.п.). В safe расте не создаёт, а если создаёт - то это баг и будет исправлен. Что тут сложного?

В STL от MS есть много проверок выхода за границы в отладочных сборках или при включенной директиве препроцессора. В паскале проверки выхода за границы существовали испокон веков. Проблема с ними только в Си, у которого подобной фичи нет, как нет архитектуры языка, поскольку язык в принципе не проектировался со времен BCPL, который писал Ричардс, а не индусы Керниган и Ритчи.

Почитал. Это полный ******.

Проблема: каст флоатов в целочисленные типы является UB, если значение выходит за рамки допустимых значений целевого типа. Например, inf (но не только).

Решение вменяемого человека: либо ничего не делать, либо ввести [отключаемую] проверку с выбросом исключения в случае возниковения такой проблемы. Так делает большинство языков.

Решение раста: молча сатурируем значения, пользователь никак не уведомляется о произошедшем (ну да, исключений-то нет). Чеки не отключаются, производительность проседает на ~20% в крейтах, активно использующих такие касты. Так делает только Java.

Отлично, просто отлично.

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

У меня снова и снова возникает тот же вопрос: за что же тебя все-таки взяли в FAANG? За обучаемость и способность с радостью писать на корпоративном языке? В принципе, я уже видел подобного крестовика из гугля, который рассказывал, что «лучше работы в мире нету, чем писать на крестах».

Rust’s rich type system and ownership model guarantee memory-safety (с точки зрения Rust) and thread-safety (с точки зрения Rust)

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

Проверяют методы *::at(size_t), не проверяют доступы по subscript operator (*::operator[])

Это поведение стандарта, но никто не запрещает реализации проверять и по subscript.

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

Сохранил эргономичность? То есть, эти ёлочки типов — это, по-твоему, «сохранил эргономичность».

Например математика может вызывать переполнение и можно было после каждой операции возвращать Result, иначе unsafe. Все как ты сказал. Но решили так

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

Настолько плевать, что не могу молчать.

В программе из 10к строк ты можешь 99% времени писать, не заботясь о переполнениях, освобождениях памяти, 100500 целочисленных типах, переданных без всяких гарантий ссылках, убогих строках, и вот этим всем легаси.

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

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

Если бы только двадцать.

Сишники/плюсовики так каждый раз млеют от мысли о едином репозитарии и универсальной системе сборки.

Удобно только для деплоя. Не испытываю никаких проблем из-за отсутствия единого (а разве пойнт карго был не в возможности создания раздельных?) репозитория и универсальной системы сборки в dev-окружении.

о от crates/cargo их прямо корчит

Кого корчит, где корчит? Хватит писать общие фразы, давай конкретику.

Про нормальные современные строки я молчу.

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

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

99% разрабов не пишут этого софта. А 1% может и на сишке пописать.

Да, согласен. В libstdc++ в hardened режиме так и делают.

Ну и кстати https://habr.com/ru/company/alconost/blog/168449/ отличный пример того сколько может стоить 1 лишняя секунда работы компьютера

А у меня есть вопрос: почему страница должна грузиться дольше 100 мс? 1 секунда — это очень, очень много.

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

А потом ты проснулся в обоссаной кровати.

Хороший вопрос. Всё дело в дизайнерах.

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

С точки зрения коммерции вообще пофигу, потому что ИНДУСтрия, как обычно, выберет говно. Я же обсуждаю раст для души, чтобы за несколько дней узнать о языке то, на что бы понадобилось не меньше месяца самостоятельного изучения.

И я должен заметить, что таки что-то полезное я для себя извлек. Например, что на расте можно объявлять все функции как «unsafe fn», и спокойно себе писать на Box-ах без лишних заморочек, с удобными struct и union, с интерфейсами на trait-ах, с продвинутым выводом типов, и с макросами. Интересно, насколько unsafe функции будут быстрее компилироваться, чем safe?

Да, если не обрабатывать ошибки и вызывать unwrap в каждой строчке. В std любая функция, которая может вызвать некорректный результат, возвращает Option или Result.

В Си функции тоже могут возвращать ошибку. И тоже будут проблемы только если не обрабатывать ошибку. И дальше чо? Чем тогда раст лучше Си?

ИНДУСтрия, как обычно, выберет говно

А важно то, во что говно превратиться.