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

Как написать например вектор? В итоге кто-то должен выделить указатель памяти, нужно как-то читать и писать по индексам, переписать новый вектор при увеличении буфера через memcpy. Эти операции будут unsafe

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

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

Если это поднимает твою самооценку, можешь считать и так. Я предпочитаю думать об этом как о калькуляторе: можно и в столбик посчитать, сколько 156728х23789, а можно просто воспользоваться специализированным ПО. Если при прочих равных управление памятью можно поручить компилятору, то зачем с этим ковыряться вручную?

Кстати, в спорах Си вс. С++ поклонники последнего любят приводить аргумент «вы там вручную malloc()/free(), когда весь мир уже автоматизировал процесс, ахах!». Но в случае с Раст это как-то не работает, видимо)

даже 50 ядер не спасают

А вот ccache спасает

Эм-м-м... я сейчас не понял прикола. А разве то, что делает ccache, системы сборки C/C++ не делают из коробки?

Лол, как мне всегда доставляют плюсовики, которые гордятся своими мазохистскими склонностями

Чини детектор и смотри профиль.

А разве то, что делает ccache, системы сборки C/C++ не делают из коробки

Нет, у них другие задачи.

Внутри и у Си, и у Раст, и у Джавы, и даже у Питона совсем небезопасные системные вызовы

Это не «внутри». «Внутри» — это компилятор. А стандартная библиотека — это рядом. Вот у тебя рядом стоит safe программа на расте, а рядом с ней — совершенно небезопасный модуль на внешне подобном языке, но с директивами unsafe. Причем, у C/C++/Java такого деления нет, библиотека и сами программы пишутся на одном и том же языке. Эта проблема есть у Python, который в этом плане очень похож на Rust, то есть — безопасен до первого сегфолта из-за «неправильного» вызова функции стандартной библиотеки.

А разве то, что делает ccache, системы сборки C/C++ не делают из коробки

Нет, у них другие задачи

Нет те же. ccache нужен для ускорения билдов с нуля, но это бессмысленно делать с ccache, потому что он сам может выдавать тухлятину, для искореннения которой и нужна была чистая сборка. А если сборка не чистая, то уже скомпилированные и не измененные файлы не будут перекомпилироваться.

Чини детектор и смотри профиль.

А, ок, то есть ты ещё и в Плюсах не силён, подшиваем к делу.

Нет те же

Давайте возьмём самую популярную систему сборки — мэйк. У неё задача сильно так отличает от ccache.

ccache нужен для ускорения билдов с нуля

Нет, повторных сборок.

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

Хоспади, да нет у раста никакой ниши. Железячники и отбитые ядерные системщики со своей сишечки никуда не слезут, кто им даст ломать все на полном ходу и переходить на другие технологии? А высоконагруженные сервисы - с этим лучше взять Go или java, там все уже очень хорошо и с производительностью и с безопасностью. Что остается? Я скажу, это хипстеры будут переписывать свои тормозные говноподелки с пистона на раст. Но говном они быть не перестанут.

Ты определись уже, под кого косишь, под 15-летнего поцика или под 50-летнего желчного социопата. Пока легенда не очень уживается.

Наконец-то всё ясно. Срочно пишите в FAANG, требуйте не меньше 50% процентов от денег, сэкономленных при отказе от раста.

А что не так.

Раст тут не причем.

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

а группа FAANG использует растишку? где можно почитать

А ты и в расте этого не сможешь добиться.

Другие же смогли.

На каждый чих тебе нужны unsafe контейнеры

Не нужны.

где тот же Arc штатно допускает дедлок — это считается «безопасным» поведением.

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

println! магией реализовывается?

Несущественно. Можно смело считать, что магией.

…

Нерелевантная информация.

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

Хочешь сказать, что раст никогда не дорастёт до больших проектов?..

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

К счастью разработчика языка не разделяют твоё мнение и постоянно (ну или ладно: периодически) борются за время сборки. cargo check помогает… пока не надо запускать тесты.

ccache нужен для ускорения билдов с нуля

У меня билд с нуля ccache замедляет. Выше уже сказали, что он для ускорения пересборки.

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

К сожалению, классические системы сборки полагаются на временные отпечатки файлов зависимостей, чтобы определить изменились ли они или нет, и, соответственно, нужно ли перекомпилировать. Например, git наносит тут удар: у него файлы не обладают таймстемпами (можно обойти с помощью git-restore-mtime). ccache хитрее. Но вот как минимум из-за создания контрольных сумм билд с нуля и замедляется.

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

Go или java

хорошо с производительностью

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

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

Я бы с радостью воспользовался компилятором, который умеет управлять памятью. Проблема в том, что компилятор Rust этого делать не умеет — памятью управляет unsafe код. В том числе RAII-конструкторы/деструкторы. Так-то и Си «управляет памятью», выделяя место под локальные переменные в стэке.

А разве то, что делает ccache, системы сборки C/C++ не делают из коробки

Нет, у них другие задачи

Makefile позволяет описать, что при изменении одного файла должна выполняться команда по обновлению зависимого файла (то есть компиляция объектника). Таким образом в роли «кэша» выступают ранее сгенерированные объектники. Чем ccache отличается?

Чем ccache отличается

Отсутствием соития с компьютером. Никто не пишет проверку файлов в мэйкфайле. И ладно бы ещё нинджа.

Потому что могу сделать язык лучше, но он никому не нужен — индустрия будет еще минимум 5-10 лет сидеть на C++/Java/C#, даже если мой язык окажется божественным и неповторимым.

Почему сразу такое пораженческое настроение? Всё-таки новые языки вполне могут взлететь. Да, «захватить мир» (вытеснить джавy) нереально, но занять нишу можно. Вон скалу теснит котлин, да и развитие самой джавы, но язык живёт так как он предлагает не просто «улучшенную джаву», но и уникальные фичи. Хотя ты, вероятно, не оценишь так как недолюбливаешь функциональное программирование и прочую «заумь».

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

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

О чём именно ты говоришь?

С тем, что можно было сделать лучше я согласен, но на мой взгляд, упирались они скорее в недостаток времени/разработчиков (то есть денег). Посмотрим изменится ли что-то с переходом от мозиллы к отдельной организации. Может специализацию с GAT-ами быстрее допилят…

А какой компилятор ей умеет управлять со 100% гарантией? И откуда вдруг такие манёвры, кто в итоге виноват, компилятор или индусы с их ансейф блоками? Не торопись с ответами, а то как-то логика не прослеживается.

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

Я в unsafe коде на Rust потру стэк, используя некорректный указатель. И каким образом компилятор меня от этого защитит? Мой аргумент

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

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

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

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

Кстати, в спорах Си вс. С++ поклонники последнего любят приводить аргумент «вы там вручную malloc()/free(), когда весь мир уже автоматизировал процесс, ахах!».

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

А также если у тебя нет malloc/free (ручных или авто), то с GC надо изворачиваться с переиспользованием выделенной памяти/объектов, чтобы минимизировать потери на GC. Хотя и в Си, и в Си++ тоже, ведь, есть правило хорошего тона как можно реже выделять/освобождать память (если хочется производительности), и, значит, тоже будут использовать пулы памяти.

а группа FAANG использует растишку? где можно почитать

https://engineering.fb.com/2021/04/29/developer-tools/rust/

https://aws.amazon.com/blogs/opensource/tag/rust/

https://security.googleblog.com/2021/04/rust-in-android-platform.html

Apple вроде чего-то собирались переписывать, но это не точно https://twitter.com/oskargroth/status/1301502690409709568

и всё очень жирно

В смысле?

Дыры в якобы безопасной модели.

Это тоже интересно, если есть конкретика.

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

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

В C# тоже есть unsafe, например.

Ну и непонятно почему ты противопоставляешь использование unsafe и сишные библиотеки? В расте это часть ансейфа.

Другие же смогли

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

На каждый чих тебе нужны unsafe контейнеры

Не нужны

А тогда ты даже не сможешь написать hello world, потому что макрос println очень интенсивно использует unsafe контейнеры.

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

https://gitlab.redox-os.org/redox-os/kernel

500 unsafe-ов на 20 тыс строк сорцов, включая комментарии. Естественно, это только прямые unsafe-ы — было бы интересно посчитать, сколько еще строк использует косвенные небезопасные операции через макросы, функции, и контейнеры.

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

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

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

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

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

К счастью разработчика языка не разделяют твоё мнение и постоянно (ну или ладно: периодически) борются за время сборки. cargo check помогает… пока не надо запускать тесты

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

Не-отравляющий unsafe.

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

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

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

В прошлой теме показали, что любую ошибку на С++ можно повторить на Rust. Как например разыменование нулевого указателя.

Это и на джаве можно. Вся разница в том насколько это легко сделать случайно.

git наносит тут удар: у него файлы не обладают таймстемпами (можно обойти с помощью git-restore-mtime). ccache хитрее. Но вот как минимум из-за создания контрольных сумм билд с нуля и замедляется

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

И что ж тогда получается? Если отметка времени изменения у файла соответствует измененности его содержимого — тогда Makefile может делать почти то же, что и ccache? Естественно, за исключением добавления/удаления пробелов и переводов строк в файлах — но это пофигу вообще, обычно в разработке роль такого перфекционизма незаметна.

Отсутствием соития с компьютером. Никто не пишет проверку файлов в мэйкфайле. И ладно бы ещё нинджа

Make проверяет отметку времени изменения у зависимостей.

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

До какого уровня должна быть совместимость? Если мы хотим так, чтобы можно было сразу сесть и развивать имеющийся проект, то это получится какой-нибудь С+++, который должен будет уметь все старые фичи, да ещё и как-то впихнуть новые без поломки. Это непросто, если вообще реально.

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

И 0 предупреждений: https://gcc.godbolt.org/z/oqTG8P545

Зачем все эти сложности?

let mut p: *mut u8 = ptr::null_mut();
unsafe { *p = 5; }

Только что это должно показать? Что ансейф раст не безопаснее С/С++? Разве с этим кто-то спорит?

интересненько

Зачем все эти сложности?

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

https://www.linux.org.ru/forum/talks/16325849?cid=16327457

Было тут обсуждение с автором темы о C++ vs C#. Пришли к выводу, что для создания игр пока C++ лучше. Посмотрим, сможет ли Раст эту нишу отъесть. Пока вроде не особо стремится.

Стремится, да ещё как: https://gamedev.rs/

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

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

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

А тогда ты даже не сможешь написать hello world, потому что макрос println очень интенсивно использует unsafe контейнеры.

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

А если твой макрос позволяет в безопасном коде допускать небезопасное поведение, значит в нём баг и его нужно исправить. Благо, что в реальном коде на Rust unsafe-кода очень мало и его всегда можно внимательно изучить на предмет багов и уязвимостей.

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

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

Естественно, это только прямые unsafe-ы — было бы интересно посчитать, сколько еще строк использует косвенные небезопасные операции через макросы, функции, и контейнеры.

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

Думаю в этом корень твоих заблуждений касательно Rust.

Но вот беда: если ты работаешь с разделяемыми данными, то этот плюс множится на ноль директивой unsafe. Которая единственная позволяет работать с разделяемыми данными.

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

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

Почему сразу такое пораженческое настроение? Всё-таки новые языки вполне могут взлететь

Ладно бы еще в 90-х годах. А сейчас посмотри на статистику популярности ЯП — никому твоя байтомолотилка не нужна, всем подавай скрипты, в крайнем случае C#/Java. Ниши для низкого уровня сужаются, и это всё на фоне огромного наследия. Посмотри на те же ОС, которые уже черт знает сколько лет новые не создаются.

Хотя ты, вероятно, не оценишь так как недолюбливаешь функциональное программирование и прочую «заумь»

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

В общем, если ты правда веришь, что можешь чем-то удивить, то я считаю, что надо пробовать. Опыт-то точно будет интересным

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

Работать надо, в том числе, над формированием сообщества. Вон вокруг мёртвого (к сожалению) немерле до сих есть маленький интерес, а разработчики можно сказать, что вообще ничего не делали для популяризации, кроме срачей на рсдн

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

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

О чём именно ты говоришь?
С тем, что можно было сделать лучше я согласен, но на мой взгляд, упирались они скорее в недостаток времени/разработчиков (то есть денег). Посмотрим изменится ли что-то с переходом от мозиллы к отдельной организации. Может специализацию с GAT-ами быстрее допилят

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

Аналогичная ситуация с питоном: исправить архитектурные проблемы в интерпретаторе 1991 года на 12 тыс строк, написанного за лето, не стоило почти ничего; исправить их во второй/третьей мажорной версии компилятора не могут уже десятилетиями, хотя даже сам всемогущий гугл делал подход к снаряду.

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

Зато JVM не написана (целиком) на джаве.

А какой компилятор ей умеет управлять со 100% гарантией?

100% — это чтобы даже системные вызовы были безупречно безопасными? Я боюсь, что таких языков нету. Но Java очень близко подобралась к этой цифре, поскольку у нее даже стандартная либа написана на безопасных коннструкциях, в отличие от Rust, у которого в стандартной либе сплошной unsafe.