Опубликован релиз языка программирования общего назначения Rust 1.75, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60364
Очень радостно, что раст уже в ядре. Лет через 15 всё ядро уж точно будет переписано на это чудо техники!
Версия ядра 1.0 вышла в 1994 году, те, будем считать, 30 лет.
Так что переписать (и дописать новое) за 15 - это будет отличный результат.
Переписывать быстрее и нейронки вполне помогают
Не спасибо, ими разве что лефтпады править.Более того, переписать просто в лоб не получится, скорее всего нужно будет менять код и взаимосвязи.
Особенно хорошо нейронки справляются со sql. Только не плачь, когда выпнут.
Нейронками можно и из Раста в Си конвертировать все нужное и тем самым избавится от лишних зависимостей.
Если конвертить из Раста в Си, то получишь все недостатки си, только на расте.
Куча unsafe, проблем с памятью и примитивность структур и кода.
И никакая нейронка тебе тут не поможет. Так лучше вообще не делать.
Нет конечно. Нейронки лучше всего программируют на том языке, для которого больше база в датасете, а это в первую очередь C и C++. Поэтому такой код получится еще лучше и безопаснее, чем на Расте. Она еще и пофиксит другие баги, не связанные с управлением памяти, от которых Раст вообще никак не защищает.
А что будет в датасете? Куча дырявого кода многолетней выдержки? Грязные хаки и срезание углов?
Вот обучишь на таком - оно тебе такое же и выпрограммирует.
Это скорее к кодовой базе Раста относится, им же главное побыстрее и побольше, часто пользуются трансляторами из Си, представляю какая там лапша.
Большая база в датасете формируется датасатанистом. Поэтому чего там будет больше ты знать не можешь.
А если просто тупо скормить гитхаб/гитлаб то больше там будет яваскрипта.
>Лет через 15 всё ядро уж точно будет переписано на это чудо техники!Особенно учитывая, что переписывание на БезопасТном идёт намного медленнее, чем написание на Сишке. А на разработку ядра затрачено 32 года, то ...
> медленнее, чем написание на СишкеТы посчитал только написание или добавил "закладывание багов", поиск багов, тестирование, исправление и тд?
Если нет, то верю.
СИшка - это же пхп времен 70х.
Для тех кто не освоил ассемблер и фортран, но нужно быстро х-к-х-к и продакшн.
А что, поиск багов, тестирование, исправление ошибок - это то, в чем программы на Rust не нуждаются?
Нуждаются в гораздо меньшей степени, чем у сишных прог.
"в гораздо меньшей" - это сколько именно, и откуда эти данные? А если сравнить не с Си, а например с программой Java, где вообще управлять памятью не нужно?
Микрософт насчитал что как минимум на 70%. Ссылки с отчётами легко гуглятся
Это не правда, у тебя даже прочитать не получилось без ошибок. А ты надеешься на Rust 🤨😀Там не говорилось что нужно меньше дебажить, тестировать и ловить ошибки. Там говорилось что 70% CVE фиксятся с помощью Rust, они в основном связаны с выходом за границы массива и т.п.
Надеюсь разницу между ошибкой и уязвимостью объяснять не нужно.
С++ и Zig тоже устраняют эти классы ошибок. А Zig и поболее чем, процентов 90-95%.
cve по сути критические ошибки. те это только усиливает мою мысль. если конпелятор находит больше ошибок за тебя, то и соотвественно дебажить и тестировать тоже меньше. простая логика.>С++ и Zig тоже устраняют эти классы ошибок
почему тогда и плюсовом коды тоже постоянно кучу дыр находят?
Эти ссылки в основном из предвзятых источников. Зато если копнуть глубже часто попадаются статьи, в которых описывается негативный опыт использования Раста и уход с него на другие языки.
Да, нас все обманывают, но Аноним-39 расскажет правду!
Если кто-то неоситор, то это не показатель
> описывается негативный опыт использования Раста и уход с него на другие языки.Не ради тролинга можно ссылки на статьи?
https://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-...Пока искал эту статью наткнулся на https://github.com/codic12/worm. Был написан на Rust, переписан на Nim.
Помню такие примеры, но где именно попадались и про что там не вспомню.
Вот ещё https://news.ycombinator.com/item?id=21967668
> I used to do this in Rust but I switched to zig for maintainability and readability over Rust
Конечно это вообще прям хобби проект. Но ценность не в этом.
А в том что у них была полная свобода в выборе языка, они любили и выбирали Rust, потом вынужденно, но добровольно, отказывались.
Ну, есть пример пары неосиляторов. Они пытались писать на расте как на и си, и чсх у них это не получилось. Поэтому они перешли на более сишные язычки.Но как частный случай может быть доказательством чего либо?
Да, также как и нередко встречаются те, кто использует санитайзеры и прочие анализаторы при написании на безопастном. Зачем, если "всемогущий компилятор" даёт "гарантии"? Вопрос риторический.
Это слишком сложные вопросы для. Разве они понимают что такое компилятор, что он в принципе может и нет?Для них это такая магический чёрный ящик, который делает "хорошо и безопасно" каким-то образом.
Каким разбираться не обязательно 😀
> Это слишком сложные вопросы для. Разве они понимают что такое компилятор, что
> он в принципе может и нет?А эти 'Они' с тобой сейчас в одной комнате?
Как ты можешь знать, что они понимают, что нет?> Для них это такая магический чёрный ящик, который делает "хорошо и безопасно" каким-то образом.
Не исключаю, что если они, как и ты, не читали документацию, то для них это 'магия и черный ящик'
> Каким разбираться не обязательно 😀
Ну ты не разбираешься, доку не читаешь, зато с умным видом рассуждаешь)
Хорошо что ты на зиг пишешь, мне хоть за колегу не стыдно :)
Как минимум, ошибки обращения к освобожденной памяти, или же ошибки не вызова free или де падения от обращения по нулевому указателю не нужно решать и дебажить как класс. Это регулярные ошибки или уязвимости.
Замечательно. Только существует множество инструментов для C и C++ которые помогают устранить этот класс ошибок и без Раста.
Замечательно. Только этими инструментами или не пользуются (они ведь опциональны), или они находят далеко не все классы таких ошибок.
А что, Rust находит все классы ошибок? Я вот выше и ниже задавал вопрос про мьютексы.Ответь на него, пожалуйста. Напиши так, чтобы в Rust ошибки многопоточного программирования не проявлялись.
А то оказывается что Rust не может гарантировать даже самые базовые банальные вещи.
Окстись уже. Зачем ты задаешь тупые вопросы?
Раст не находит все классы ошибок. Он предотвращает именно те, для которых был сделан и они прекрасно описаны в документации. Самый большой класс проблем с владением. А все остальные он не предотвращает.
Ну вот как можно быть таким... недалеким? Открой уже доку и прочитай наконец!
>ошибки не вызова freeНе туда воюешь, "Preventing memory leaks entirely is not one of Rust’s guarantees, meaning memory leaks are memory safe in Rust".
> А на разработку ядра затрачено 32 годада, только ведь код добавлялся не линейно.
а платиновые спонсоры скажут "надо" и работа закипит
> а платиновые спонсоры скажут "надо" и работа закипиттак уже сказали и Торвальдс разрешил, но сам он не увидел пользы от раста и энтузиазма нет
Ага, 9 женщин родят ребёнка через месяц.
Ага, ведь ядро это 1 большой файл на С 😂
Они таки закопают ведро.
Лицензия на редхат в разрезе 5 лет не сильно дешевле лицензий на винду... винде правда кал костов добавляет, но если мы берём сервис, который на аутентификацию в самой ос не завязан - кала надо мало. Для переходного периода из коробки уже есть WSL.
А смысл сравнивать стоимость рхел и венды?
Жаль, что времени этого не будет? )
> В состав добавлен оптимизатор BOLTНу раз добавлен... ладно, хорошо хоть не "на код положен"
Хотя если "прирост скорости сборки до 24.7%", то можно и ценой 10.9% роста размера инструмента.
Сейчас что ссд, что память стоят копейки, зато нищуки перестанут лезть в ядро.
Ага, embedded == нищуки.
>Ага, embeddedдля embedded придумали кросскомпиляцию
Следующую АЭС, для питания богатых сборок, построят напротив вашего дома
пф..! АЭС это уже прошлый век, вот если бы термояд (например Mr. Fusion Home Energy Reactor)))...
но придется ограничиться солнечными панелями на крыше
Э, нет, солнечных панелей вам даже на один лишь браузер будущего не хватит.
Глупо изучать новый сырой язык со сложным синтаксисом только ради защиты от небольшой части ошибок, связанных с неправильным управлением памятью. Проще воспользоватся инструментами вроде cppcheck или другими статическими анализаторами. Вот кстати большой список таких инструментов: https://github.com/analysis-tools-dev/static-analysis
Хоть один адекватный человек на сайте.
Мне кажется это единственная причину батхерта в сторону раста, когда уже убито множество человекочасов на изучение C++, а тут набирает популярность прямой конкурент, который позволяет проще писать поддерживаемый производительный код с минимизацией выстрелов в ногу.
Негативное восприятие всего лишь потому что вместо С++ со его реальными недостатками пропагандисты Раста всем навязывают C++ номер два с таким же убогим синтаксисом, без ООП, зато с CoC и повесточкой.
Мне кажется, про раст вы знаете чисто из комментариев на опеннете. Вместо ООП есть куда более удобные механизмы, синтаксис куда доканичнее и понятнее чем в плюсах, если сравнивать аналогичные конструкция.
Вот поэтому те кто с ООП на короткой ноге в Раст ни ногой, у тех все чего нет "нинужно". Попиши без ООП большой проект, особенно математический - захлебнешся в лапше.
Я писал на java и на python, давно когда-то на C++, но композиция и интерфейсы как в go или rust (особенно в rust, по сравнению с go) удобнее и лаконичнее, нежели ООП и прекрасно работают и в масштабных проектах.Математические библиотеки прекрасно себя чувствует и пишутся на rust.
>Я писал на java и на python, давно когда-то на C++Я писал секретный проект CIA на расте в 200kk LOC, переписал на него целиком ядро winglows (тоже секретный проект, так что сурсов не будет) и "композиция и интерфейсы" там менее "удобны и лаконичны", чем в NASM.
Математические библиотеки на расте - анъюзабл булщыт.
В математических проектах ООП ненужно вообще. Julia использует ФП и множественную диспетчеризацию, которая гораздо мощнее и лучше, чем ООП.
Вы отождествляете ООП и синтаксис конкретной реализации (C++)?
Проблема в самом языке. Очень он неудачный получился. Не замена С++, а как правильно здесь сказали, С++2. Да, получше.Да, чуток получше, чуток безопаснее. А гемора с ним намного больше.
Уже не один проект он него отказался, хотя явно там фанатики были. Тащили до конца, но не вышло.
А что он появился - для С++ это здорово. Это значит часть программистов ушла туда и начала снова и заново переписывать всё, от Hello World до очень серьезных вещей.
И что в нем прям очень неудачного? Мне кажется, одно лишь отсутствие нулевых указателей это эпик вин, не говоря о других удобных и полезных вещах.
Чел, не ведись на троля. Если ты не в курсе, Витюшка - это знатный местный критик Раста, который не в зуб ногой ни в Расте, ни в C++. Он из темы в тему постит забористую дичь, причем повторяет одну и ту же чушь даже после того, как в предыдущей теме его ткнули носом в факты.
Витюшка пытался вкатится в программирование на Rust, задал тут невинный вопрос, так растоманы его вместо ответа обложили хренами с ног до головы. Достойно встретили новичка, что ни говори, вот у него теперь и аллергия на Rust.
Неа, он пришел со словами ваш раст овно, а воот зиг и крабон огого!
На вопрос "почему? что тебя не получилось?", начал рассказывать чушь, которую можно развеять просто открыв документацию.> Достойно встретили новичка, что ни говори, вот у него теперь и аллергия на Rust.
Минус конкурент)?
С чего ты решил, что я хороший и добрый человек)?
Да ты не переживай, ты мне не конкурент.Про Carbon я вообще ничего не говорил. Это как Rust, да получше, но не настолько чтобы на него переписывать код, если это не Hello World. Ну у Google денег много, они могут баловаться.
А там где я что-то в документации недоглядел. Так я признаю. Какой же я тролль. Принципиально это сути, конечно, не меняет.
> А там где я что-то в документации недоглядел.
> Принципиально это сути, конечно, не меняет.Ахахаха! Но вообще ты прав, в твоем случае это принципиально ничего не меняет))
Отсутствие нулевых указателей также есть и в Zig. Это большой win, как ты сказал.Но в C++ это делается буквально парой строчек. Пользовательский тип, который инкапсулирует сырой указатель, пара переопределенных операторов, move конструкторы и готово. Проверяй в конструкторе что указатель не null.
Это разные вещи - принципиально не выразимо или же можно сделать если очень захотеть и другие будут тоже правильно делать.Rust не единственный язык, который отказался от null, но он самый популярный и развитый из онных
А потом говорят что это я Rust не знаю?Вы сами то его знаете, программисты на Rust?
Всё там прекрасно принципиально выразимо. И никаких гарантий что какой-то кривожоп не понапишет race conditions которые десятками лет отлавливать будешь потом.
Мы же обсуждали прлблему нулевых указателей. Тут вам возразить нечем и соскакиваете с темы
Нет, это замечательно. Эта ошибка которая должна быть исправлена в новом языке. Я только это приветствую. Речь то не об этом была.
Давай по новой, Витюшка, все фигня! (с)Ты опять пришел позориться своими "знаниями" в области Раст?
В этот раз будешь заливать про зиг, свою уникальную задачу, когда "несколько потоков одновременно пользуют один кусок памяти" и прочие ламповые истории?
Или ты, сегодня, придумал что-то новое?
Есть кое-что поинтереснее и посвежее.Есть код мьютекса (спинлока). Естественно это суперкритичный к качеству и надёжности код. Естественно написан на Rust.
Докажи, пожалуйста, с помощью Rust (который безопасный по памяти и гонкам данных!) что этот код:
1. Действительно даёт mutual exclusion доступ к критической секции (т.е. работает корректно)
2. Является deadlock-free
3. Является starvation-freeА то у вас одни hello world только безопасные 😀 Надо на реальных примерах.
А открыть и прочитать тот же rustbook не судьба?)
Это не ответ (и почему-то я на 100% уверен что там такого нет).Но ты не сливайся так сразу. Ты сюда пиши)))
Я жду ответа от Rust гуру. Вы должны защитить поруганную честь и достоинство этого языка.
Всё таки упор на безопасность!
Зачем мне в комментариях цитировать то что и так описано в книге, а чтобы грамотно по полочкам разложить, это минимум пост нужно писать, а не комментарий.
>Зачем мне в комментариях цитировать то что и так описано в книгеЧтобы показать, что это действительно есть в книге, а не является плодом больного воображения анонима.
Чувак, уж кому-кому, а тебе мы точно ничего не должны)) Нам про раст уже ничего доказывать не нужно.Более того, если ты думаешь, что твои жиденькие набросы могут хоть как-то задеть "честь и достоинство этого языка"... то лучше обратиться к профильному специалисту и полечить свое самомнение и проблему одушевления предметов.
В гугл я тоже посылать умею. Слив защитан.
Ответ - никак. Твой Rust ни черта этого не умеет.В книге The Art of Multiprocessing Programming корректность доказывается с помощью построения логических теорем, с доказательством на листочке. По индукции или методом от противного. На листочке, ручками!
Это самые сложные, самые частые ошибки, самые опасные.
И где твой хвалёный Rust? Где твоя защита? Где твой borrow checker?
Если вы даже мьютекс не можете написать безопасный?
В комментариях не уместит нормальное объяснение. А если пытаешься, то в ответ "гы гы, какой же раст безопасный, если я в пару строчек могу сделать утечку памяти", хотя безопасность языка она исключении других ошибк. Аналогично и с другим.
Многопоточное программирование сейчас абсолютно везде, даже в роутерах домашних, на мобилках, десктопах, лэптопах, серверах.Это самый критичный код, потому что отловить его в тестах вообще невозможно. Заметить тоже - никто тебе никакой exception не кинет. Тихонько перезапишет память и всё.
А выходы за границы массивов и 90% что умеет Rust можно и в C++ сделать. В принципе это прям банальные вещи, их в runtime можно и нужно ловить.
Автор книги The Art of Multiprocessing programming - это основоположник lock free алгоритмов, гуру, эксперт мирового уровня.
И я не вижу как Rust хоть как-то решает проблему многопоточного программирования и особенно lock free алгоритмов.
И ещё ни один специалист здесь ни разу не смог ответить на мои вопросы.
В основном хиханьки да хаханьки в стиле "сам дурак" и "всё в Rust book написано"
> Уже не один проект он него отказался, хотя явно там фанатики были. Тащили до конца, но не вышло.Можно ссылки, что за проекты?
Я выше в соседней ветке подробно ответил.https://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-...
Помню больше, конечно, но найти не смогу.
Ну так уже 24 год на дворе, раст 5 лет назад был не тот, что сейчас. Мне бы хотелось линк сего года.
Типичное когнитивное искажение, когда человек ищет по ключевым словам подтверждения своих убеждений, а что с этим не соотносится- просто игнорирует
> от небольшойАхаха! Серьезно??
Посмотри сколько дыреней из-за проблема с памятью! Просто открой CVE лист для любого большого си проекта и там сплошные use-after-free или запись за пределы буфера.
А статический анализ тебе поможет только в самых примитивных случаях.
Как хорошо, что решения, касающиеся ядра, принимают профи.
Серьёзно. Потому что С++ это не С. И Rust взял очень многое напрямую из C++. Например, модель памяти и move семантику (она немного другая в Rust, более слабая, но из С++).Те в целом получается +- что на Rust, что на C++ одинаково.
Сразу видно человека, не писавшего на расте.
Жду раз...б по фактам.
Откройте багтрек любой крупной программы на С или С++, либо новости об очередных учзвимостях. В топе ошибок - ошибки работы с памятью. Также 100% уверен, что проекты на С или С++ ловили в проде падения, из-за обращений к нулевым указателям. Не только С и С++, но и все где есть null. Пока в принципе есть такая возможность стрелять в себе в ноги, это будут делать, даже самые топовые разработчики.
Я открыл крупный проект на Rust.А что это у нас тут такое по тегу safety?
https://github.com/servo/servo/issues/25726
https://github.com/servo/servo/issues/19870Что это тут у нас? 😨 Гонки данных???
https://github.com/servo/servo/issues/21186
Так Rust же не позволяет гонки данных в compile time???
где там:
- использование памяти после free
- забыли освободить память
- паденич из-за обращения к null указателю?
Use after free открытый с 2018 года
https://github.com/servo/servo/issues/21459
https://github.com/servo/servo/issues/27473
Вы тупо гуглите по ключевым словам без понимания сути issue?)
>https://github.com/servo/servo/issues/21459This testcase is crashing during the final GC when the JSContext is being destroyed.
И на чем же этот GC & JSContext написаны? не на С++ случайно?
очередной обчирон от витюши 🤷♂️
Там по трейсу видно что корень проблемы идет в c++, над которой уже идет обвязка к rust
То Раст безопасный, то теперь оказывается нет)))
А какая разница что там внизу вызывается? Я даже не хочу углубляться на набросы про С++.Обвязка то должна быть безопасной? Ради этого же всё делалось?
Или вы не можете написать безопасную обвязку над "небезопасными" языками - те ради чего вообще создавался Раст?
Ну так обвязка, несмотря на использование unsafe безопасна. Она запаниковала в рантайме, вместо того чтобы молчаливо обращаться к памяти, к которой не должна. В safe части языка такое не скомпилируется даже.
> То Раст безопасный, то теперь оказывается нетВитюшка, ты опять не в состоянии в доку заглянуть и прочитать в каких случаях Раст безопасный?
Там же немного, всего пара абзацев... Неужели это тебе так сложно?
Или после тайпскрипта у тебе вообще мозг атрофировался?> Или вы не можете написать безопасную обвязку над "небезопасными" языками
Безопасную обвязку к другим языкам (без GC) создать в принципе невозможно - потому никто не в состоянии проверить, что они там наовнокодили - даже сами авторы - и все держится на "мамой клянуcь" погромиста.
> ради чего вообще создавался Раст?
Чтобы все было написано на нем разумеется) Чтобы по максиму использовать safe code и safe либы (если ты не в курсе - существует #![forbid(unsafe_code), который позволяет вообще все либу писать только на safe подмножистве)
То есть безопастный использует нибищапащные либы на клятi сикрестах???? Не может такого быть!Почаще в лефтпады заглядывай и смотри, сколько там ансейфов, бтв.
И в чем противоречие использовать обвязки к либам на плюсах? В rust unsafe очень лимитированы, по сравнению со всей кодовой базой, да и unsafe не отключает всех проверок. В C++ в unsafe всё.
> И в чем противоречиеВ том, что бищапащность в безопастном мгновенно исчезает, как только ты линкуешься с либой, которая занимается хотя бы каким-то менеджментом памяти. И никакие обмазки тут не помогут.
> unsafe очень лимитированы, по сравнению со всей кодовой базой
> unsafe не отключает всех проверок.И это всё никак не поможет, потому что легко может произойти что-то вроде этого: play[dot]rust-lang[dot]org/?version=stable&mode=debug&edition=2021&gist=9d167c7dd188c2995d550474fa28107e
Да-да, это протечка ансейф лямбды в сейф-контекст. И учитывая приматоподобную сущность разработчиков ржавого - нет никаких гарантий, что ~~данный баг~~ данная фича уникальна.>В C++ в unsafe всё.
Твои баззворды и жонглирования терминами на меня не сработают. В крестах нет понятия "unsafe".
> И никакие обмазки тут не помогут.Работаешь с любой сторонней не-раст либой как с unsafe. Просто потому что ты не можешь знать что они там на кодили. Поэтому весь ffi идет unsafe.
> И это всё никак не поможет, потому что легко может произойти что-то вроде этого: play[dot]rust-lang[dot]org/?version=stable&mode=debug&edition=2021&gist=9d167c7dd188c2995d550474fa28107e
Ну так у тебя "бажина" локализована в unsafe секции
> Твои баззворды и жонглирования терминами на меня не сработают. В крестах нет понятия "unsafe".
Не, в крестах нет понятия safe)) Взял и попортил что угодно где угодно.
> Ну так у тебя "бажина" локализована в unsafe секцииУ тебя краткосрочная память только три буквы вмещает? Используешь нибищапащную функцию в ансейф лямбде -> используешь ансейф лямбду в сейф контексте -> получаешь всё что угодно, но только не бищапащность. Разжевал простейшую двусвязную логическую цепь специально для растовиков, можешь поблагодарить.
> Не, в крестах нет понятия safe))
Твоя софистика по прежнему не работает, выдумывай оригинальнее.
>Взял и попортил что угодно где угодно.
Также как в расте и вообще любом ЯПе. Если ЯП не позволяет выполнять команды программиста - это не ЯП, по определению.
> В том, что бищапащность в безопастном мгновенно исчезает, как только ты линкуешься с либой, которая занимается хотя бы каким-то менеджментом памяти. И никакие обмазки тут не помогут.Сразу видно спеца!
При линковке с любой либой из дыряшки ты можешь получить чужую память просто ошибке в парсинге строки в коде "не либы". Уязвимости вида "30 раз нажал энтер - получил рут" как раз показывает, что криворучки не могут нормлаьно писать ни в либе, ни в основной программе.
И вообще не нужно тянуть всякий мусор в свой проект)> Да-да, это протечка ансейф лямбды в сейф-контекст. И учитывая приматоподобную сущность
> разработчиков ржавого - нет никаких гарантий, что ~~данный баг~~ данная фича уникальна.Ого, и это рассказывает фанаты дярявости, которая пророждает 70% ошибок в крупных проектах.
Да по сравнению с этими приматами, амебы до сих пор не смогли буфер писать без переполнения.> Твои баззворды и жонглирования терминами на меня не сработают. В крестах нет понятия "unsafe".
Зато есть понятие "какаю в чужую память"
> При линковке с любой либой из дыряшки ты можешь получить чужую память
> просто ошибке в парсинге строки в коде "не либы".Причём тут сишка?
> И вообще не нужно тянуть всякий мусор в свой проект)
Согласен, а растовики должны прекратить его пропагандировать.
> Ого, и это рассказывает фанаты дярявости
Пруфай, что тут есть какие-то фанаты дырявости кроме тебя.
> Зато есть понятие "какаю в чужую память"
Какие ещё у тебя есть отклонения?
>> И вообще не нужно тянуть всякий мусор в свой проект)
> Согласен, а растовики должны прекратить его пропагандировать.Хм... а кто это знамениты Григорий, чтобы все указывать?
Может он великий пограммист? Что-то я такого не слышал) А может он сходит куда-нибудь?
Так что кушай что дали и молчи, умные дядьки разберутся что для современных яп хорошо, а что нет.>> Ого, и это рассказывает фанаты дярявости
> Пруфай, что тут есть какие-то фанаты дырявости кроме тебя.Пруф:
Дано: сишка и с++ дырявые (70% ошибок с памятью)
-> серьезные компании типа гугл и майкрософт заменяют их на раст
Фанаты этих языков -> фанаты дырявости>> Зато есть понятие "какаю в чужую память"
> Какие ещё у тебя есть отклонения?Не у меня слава богу все норм, а вот когда пограммист на нагадил в соседнюю память и теперь CVE с получением рута, то к сожалению меня это тоже касается
>знамениты ГригорийТаблетки прими, а то уже совсем безсвязную ересь пишешь.
>Так что кушай что дали и молчи
Это твоя прерогатива, как фанатика.
>умные дядьки разберутся что для современных яп хорошо, а что нет
Уже давно разобрались, именно поэтому на расте пишут только сами разрабы и те, кому занесли гранты (т.е. полтора землекопа), в то время, как остальные предпочитают выбирать инструмент соответствующий задаче, а не наоборот.
>Пруф:
Это не пруф, а твои маняфантазии. Пруфай, что:
1. ...из "70% ошибок с памятью" следует "сишка и с++ дырявые";
2. ..."серьезные компании типа майкрософт заменяют их". Раст делается выходцами из мразиллы, которой владеет гугл, поэтому в качестве примера он не подходит априори. Это всё равно, что написать "сишарпом пользуются такие крупные корпорации как майкрософт, значит это классный инструмент";
3. ...тут есть какие-то фанатики в принципе, кроме тебя.>Не у меня слава богу все норм
Лжёшь ведь, у тебя целая пачка психических отклонений, следствием чего являются обильные проекции и фантазёрство в твоей писанине.
Поэтому придумали Java. Ну и не только поэтому.
Опыт гугла подойдет?
security.googleblog.com/2021/04/rust-in-android-platform.html
Расскахывают и про проблемы с/с++, и про сложности санитайзеровРезультат через год
security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language.Большую часть нового кода пишут не на с++, а на расте
РебятаБ не ведитесь на тролля. Он вам сейчас заведет свою старую шарманку о том, что в Расте нет безопасной работы с памятью, и вообще все его пользователи - некомпетентные дураки, не раскусившие заговор.
Подождите, это же тот зиганутый, который в двух темах рассказывал про то какой раст ненадежный, а вот Зиг!..
Он еще смайликами почти каждое свое сообщение метил.
Ты лучше ответь выше про гонки данных. Их же в Rust нет благодаря borrow checker, все ловятся в compile time.И про мьютекс)
>> для любого большого си проекта
> Потому что С++ это не С.Прям Капитан Очевидность пожаловал. И? При чем тут с++?
В ядре его нету. И не будет.
Будет Rust в ядре - будет и С++. Иначе будет неинклюзивно, а это нарушение CoC.md
Раст в ядре с версии 6.1. Сейчас версия 6.7-rc7.
Ну и где там С++?
> Глупо изучать новый сырой язык со сложным синтаксисом только ради защиты от небольшой части ошибок, связанных с неправильным управлением памятьюГосподи, в каждой новости о Rust начинается один и тот же цирк, снова и снова... Вам не надоело еще?
Конечно им не надоело! Они одни и те же ошибки повторяют уже лет 30-40.
Вы про use after free и разыменовывание нулевого указателя?)
А как же выход за пределы буфера?? Тут целое созвездие стандартных проблем.Вот прям из последнего
https://www.opennet.dev/opennews/art.shtml?num=60326 - запись за пределы выделенного буфера (2 шт.)
https://www.opennet.dev/opennews/art.shtml?num=60338 - use-after-free, double-free
https://www.opennet.dev/opennews/art.shtml?num=60361 - Use after free
А могли бы просто проверить статическим анализато... постой, да они же так и сделали, ахахаха!
Если за пару десятилетий люди так и не научились писать без таких ошибок, значит никогда не научатся и это by design своцство языка.
Если за пару десятилетий люди так и не научились писать без таких ошибок, то им и Раст не поможет, только запрет на профдеятельность.
Значит закрываем программирование, потому что такие ошибки были и периодически появляются практически во всех крупных и средних проектах. И никто так и не научился за десятилетия не допускать ошибок в программировании.Правда, в языках со сборщиком мусора или моделью как в rust таких проблем нет в принципе.
Ща закон примут и все мигом начнут писать без ошибок. А пока всё "AS IS", никакие безопасТные языки от тотальной безоТвеТсТвенносТи в профессии не помогут.
> Проще воспользоватся инструментами вроде cppcheck или другими статическими анализаторамиГугл утверждает что это (и не только это) слабо помогает их андоидовским (и не только) си/плюсовым проектам. А вот задействование раста взамен си/плюсов в новых системных компонентах помогает просто ошеломительно:
https://security.googleblog.com/2022/12/memory-safe-language...
В этом вопросе я больше гуглу поверю, чем тебе.
Просто никто про эти инструменты еще не знает. Ни GOOGLE, ни kernel.org, ни MICROSOFT. Если им сообщить, то ошибки в их проектах перестанут появляться.
> При работе с голыми указателями ("*const T" и "*mut T") могут потребоваться операции добавления смещения к указателю.лет через 10 до С дорастёт по удобству работы с памятью
Удобство работы с памятью в си - это "куда хочу, туда и пишу".
Проблема что очень часто пишут мимо))
> Проблема что очень часто пишут мимогипервизоры перехватят если что, можно ведь и прямо дёртуть не тот бит и спалить чего или стереть однократно программируемую память и окирпичить проц - никакие расты не помогут от отсутсвия закладок или ошибок в железе или просто отсутствии инфы
Опыт дебага утечек памяти, или used after free или разуменовывание нулевого указателя вспоминается как страшный сон, брр..
Ну, от утечек памяти раст не защищает и не гарантирует их отсутствие. Прямо в доке так написано.А вообще не знаю языка, который бы гарантировал их отсутствие. Даже хаскель периодически течет.
Возможно что-то с формальной верификацией, но это очень специфические вещи.
Да, я больше про использование памяти после освобождения, либо же забыть освободить память и получить утечку. Это прям регулярная проблема в софте на С и С++. Языки со сборкой мусора или моделью как в rust доказывают, что такая проблема реальная и что она достаточно большая, чтобы ее решали люди и другие люди с удовольствием пользовались.
В стандарте С17 будут подвижки с безопасностью, а пока для критичных проектов есть MISRA, например. В последние годы подняли такой шум с ней, что можно подумать остальные языки программирования будут сидеть ничего не делая. В С++ сейчас безопасность памяти это одна из основных задач над которой трудятся.
> В стандарте С17 будут подвижки с безопасностьюНапомните, какой сейчас год?)
Сколько лет уходит, чтобы стандарт попал в ядро?
В каком году в ядре начали использовать С11 вместо уже окаменевшего C99?> критичных проектов
Есть Ада Спарк.
Мисра тоже неплоха, но запрет на динамические аллокации сильно сужает применимость.
В ядре начали использовать С11 в 2012 году, полную поддержку обеспечили конечно позже, учитывая размеры проекта не вижу тут ничего ненормального. SPARK конечно хорошо для своих задач, повзволяет формально верифицировать ПО. Удивлен что приложения для блокчейна пишут не на нем, а на разгильдяйском Solidity.
Ядро перешло на с11 в 2022 году. Попробуем оценить в каком перейдут на c17, если сейчас практически 2024. Я думаю где-то 2029-2030.> Удивлен что приложения для блокчейна пишут не на нем,
Думаю потому что слишком дорого.
А блокчейн много на чем пишут, в том числе и на расте.
Так это окончательно объявили. А если проблемы с управлением памятью настолько реальны, как нас убеждают, то внедрение механизмов безопасности могут форсировать и скорее всего форсируют. Даже самые отъявленые фанаты Раста признают, что переписать ядро на Расте просто нереально, ни к 2030, ни к 2050. А блокчейн много где и на С++ пишут, немало видел на Java, бывало и на Котлине, там зоопарк огого.
Так все ядро никто даже и не собирается переписывать. Как раз самые отъявленные фанаты это понимают)
Но переписать самые проблемные части, начать писать новый функционал, начать писать драйвера, чтобы одна паршивая овца не роняла всю систему - это вполне реальное развитие событий.
Ну так эту проблему (в целом довольно надуманную) и решает введение нового стандарта и новых инструментов обнаружения утечек, и не нужно это странное двуязычие, или даже скорее мультиязычие, потому что за Растом в ядро наверняка последуют и другие языки.
Проблема не надуманная. Как ни откроешь новость про CVE в ядре - то там почти всегда проблемы с памятью. И намного реже с логикой.> и решает введение нового стандарта
почему тогда его до сих пор нет?)
> и новых инструментов обнаружения утечек
и их тоже нет?
Как нет, только что же обсуждали :) Какая избирательная память.
>инструментов обнаружения утечекОй сколько я могу их накидать :)
Накидать ты то можешь, не сомневаюсь. А вот какие из них реально что-то гарантируют?Вот целая куча дыреней в OpenSSL/LibreSSL https://www.opennet.dev/opennews/art.shtml?num=58622
- чтение из области вне границ буфера
- Use-after-free
- двойное освобождение памяти
- некорректное разыменование указателя
- разыменование указателя NULL (x2)
ну и еще одна логическая проблема, которая решается нормальными типамиПри этом ворнинги включены, оба проекта обмазаны санитайзерами по самое немогу - и memory, и thread, и еще куча других
https://github.com/openssl/openssl/actions/runs/4124496105
Там даже фаззинг какой-то есть.И что? Помогли тебе анализаторы? Как тогда они смогли собрать практически полное булщит-бинго?
Лол, да ты только потому знаешь об этих багах что их как раз выявили и пофиксили с помощью тех самых анализаторов. Л - логика.
1. Пруфы в студию. Ну, что именно эти баги были найдены именно санитайзерами.
2. Как этот код попал в кодовую базу, если бы санитайзер просто не пропустил бы PR? (вопрос риторический)ну и вопрос со звездочкой
3. Сколько лет эти дырени спокойненько жили в либах?
Вот хороший пример https://www.opennet.dev/opennews/art.shtml?num=59906
"Уязвимости в библиотеках X.Org, две из которых присутствуют с 1988 года"
- выход за границы буфера
- исчерпание стека при обработке специально оформленных данных
- целочисленное переполнение приводящее к переполнению кучи
- чтение из областей вне границ выделенной памятиЭти дыры старше половины посетителей опеннета))
Ой, как же их не замечали столько-то лет? Есть же так много прекрасно работающих инструментов для этого))
Вот также будут и в 2050 находить ошибки в немногочисленных легаси проектах на Rust.
Будут находить именно use-after-free, buffer-overrun и тд?))
А что, баги в программах перечисленными категориями исчерпываются? ;)
Нет конечно. Но тут кто-то считал, что для CVE - 70% проблемы с памятью. И в это охотно верится.
И исключение - огромный плюс к безопасности. А баги в логике будут любых языках.
Проблемы с управлением памятью есть, это подтверждает наличие языков со сборкой мусора, которые появились очень давно. Не было бы проблемы с управлением памятью, никто бы не создавал такие языки и они бы не были популярными.
>В каком году в ядре начали использовать С11 вместо уже окаменевшего C99?Такого события не было - C11 начали использовать вместо окаменевшего C89.
>вместо окаменевшего C89for (int i=0; .... вроде бы, уже очень давно можно было писать.
> есть MISRA, напримерона платная для начала. Намного хуже что в gcc практически невозможно включить все варнинги и санитайзеры внятным способом и для проверки мисра-комплиант надо ещё внешний чекер. В платных компиляторах наверно лучше с этим но я ими не пользуюсь.
Платный стандарт, а он и для С внезапно платный (чистовик), и ГОСТы на практике и много еще чего.
PVS-Studio вроде предлагал бесплатную лицензию на один год для проектов с открытым исходным кодом. Наверняка есть и другие пути для некоммерческого проекта, а коммерческие пусть платят.
> Платный стандарт, а он и для С внезапно платный (чистовик)поддержка различных стандартов С и С++ в gcc есть а мисры я там не наблюдаю
> PVS-Studio вроде предлагал бесплатную лицензию
это внешний анализатор, так можно и Frama-C ещё вспомнить, только много кто этим пользуется ? Rust удобен тем что весь анализ кода в одном открытом бесплатном компиляторе.
Ну так внешнего анализатора и достаточно чтобы получить грубо говоря 90% преимуществ Раста и еще выловить баги которые и Раст никак не помогает предотвратить. И главное для этого не нужно менять свой основной язык, что для многих означает потерю работы.Уже есть коммерческие решения для MISRA, свободные как обычно будут с задержкой, в GCC процесс идет. Пока что можно пользоватся бесплатной версией PVS-Studio и аддоном MISRA для CppCheck. Глупо считать что Раст предлагает в этом что-то уникальное или новое.
> Ну так внешнего анализатора и достаточно чтобы получить грубо говоря 90% преимуществ РастаИнтересная цифра! А можно, хотя бы примерно, методику ее расчета? Пока похоже на "пальцем в небо".
> и еще выловить баги которые и Раст никак не помогает предотвратить.
А можно примеры?
Если ты о фаззинге - то для раст тоже есть внешние инструменты.> И главное для этого не нужно менять свой основной язык, что для многих означает потерю работы.
Вот скажу честно, мне плевать сколько бракоделов-неосиляторов пойдут работать дворниками.
Они за 30 лет не научились память чистить не больше одного раза и за буфер не выходить, так что совершенно не жалко.
Гугл за 2 месяца переучивает людей с Python, Java и Go, на Раст - без потери производительности.
Если эти "профи" не могут выучить новый язык, то они просто плохие программисты.
(То что они ʼне хотятʼ - в это я охотно поверю)> Пока что можно пользоватся бесплатной версией PVS-Studio и аддоном MISRA для CppCheck. Глупо считать что Раст предлагает в этом что-то уникальное или новое.
Выше покащали пример, что куча санитайзеров работала... и не сработала.
И на минуточку это криптография!
opennet.ru/openforum/vsluhforumID3/132453.html#78
Ты сначала посмотри на количество вакансий для разработчиков на Rust, а потом рассуждай тут про дворников. А то может оказатся что для любителя Раста совмещать работу дворника с домашним проектом на любимом языке может оказатся еще не самым плохим вариантом )))
Количество вакансий просто убийственный аргумент)))
А ведь JSников и пыхеров еще больше чем сишников...
> Уже есть коммерческие решения для MISRAсоблюдение правил мисры не даёт никаких гарантий а гигантское ядро по ним написать шансов ноль
> Глупо считать что Раст предлагает в этом что-то уникальное или новое
он даёт гарантии и это по умолчанию - достаточно просто собрать прожект, назови если такой неглупый аналог для С. С тем же пивасом вспотеешь парсить логи и всё равно найдёшь только незначительную часть ошибок.
Раст дает гарантии только по ограниченному классу ошибок, остальные лови ручками как и в любом другом языке.
только этот ограниченный класс составляет 70% ошибок, причем многие из них - критические, позволяющие хакнуть программу/систему. Можно сформулировать и так - подавляющее большинство ошибок, которые являются критическими и позволяют взломать систему и получить над ней контроль - как раз из этого самого "ограниченного класса ошибок".
Не очень понятно, зачем нужен недописаный Hermit, когда есть уже готовые стабильные проекты IncludeOS, Nanos, наконец Unikraft.
Потому что опенсорс - это про NIH, велосипедостроение и 'фигня какая-то, я точно лучше сделаю'.
Так всегда было, независимо от языков программирования.
Как будто что то плохое ...
Смотря откуда взглянуть. Если с позиции Васяна - то да, плодишь себе стотыщпицотный нотепад и думаешь, что сейчас-то ты точно плюнул в вечность. А с позиции камьюнити это УЖАСНО - вместо выбора пакетов для инсталляции, надо погружаться в 3-часовую медитацию "зачем нужен пакет S, чем он отличается от Q, что такое Q-next и превосходит ли он S++". Мириады пакетов непонятной степени отлаженности, готовности в целом и конечно же категорически не нужное РАСПЫЛЕНИЕ СИЛ. Я бы рад помочь *одному* редактору, плагинов там понаписать, но как я его выберу? Этот умеет в синтаксис Perl, а вот этот мультитабный, а тот вообще в консоли работает! Ты теряешься в этом месиве DIY программ, потому что ни одна (нехорошая редиска) не скажет, что его пакет - г0внŏ. Хотя прекрасно знает, что там внутри чёрт ногу сломит. Таковы дилетанты FOSS - сс-ык-уны и посредственности, никто не научен брать на себя ответственность. А нет ответственности - НИКОГДА не будет нормальных фаворитов.
Конкуренция-с. Как было с VHS, дискетами, дисками, хардами, интерфейсами...
Оказывается, здесь столько системных программистов, которых так заботит безопасность обращения к памяти на нулевом уровне ядра! Куда же делись прикладные программисты, которым ехать, а не шашечки?
Прикладники ничего не знают про эти "вещи в себе". Вот например:> всю необходимую функциональность, не привязываясь к ядру ОС и системным библиотекам
А как это чудо взаимодействует с железом?
Как отправляет пакеты в сеть?
Как записывает на диск?
Как рисует на мониторе?Чует моё сердце, что создали очередной "виртуально-абстрактный гипервизор в контейнере" не имеющий никакого прикладного применения и рады до ушей.
Операционная система и есть библиотека. А исполняться оно должно в виртуальной машине на виртуальном процессоре, считай аналог голого железа. А не в контейнере.
> которым ехать, а не шашечкиЭто те, которым говняк-говняк и в прод? Да куча их, посмотри выше по ветке))
Почему-то под ехать ваша братия всю дорогу понимает недоязычки с нулевой гибкостью, "нюансы" которых нужно специально "изучать" (вместо изучения теории категорий, например), чтобы программа работала корректно.
Я тут. Помимо безопасной работы с памятью без сборщика мусора, там есть еще много удобных zero-cost абстракций и нет проблем с нулевыми указателями, которые регулярно всплыывют и на c++, и в go и в питоне и в jvm языках и в других. Также модель, по которой происходит работа с памятью прекрасно работает и с другими ресурсами, как параллельность или же забыть освободить какой-то mutex.
Отлично! Я тебя нашёл. Да что там освобождение мьютекса!Давай хотя бы сначала попробуем написать мьютекс безопасный на Rust!
Есть код мьютекса (спинлока). Естественно это суперкритичный к качеству и надёжности код. Естественно написан на Rust.
Докажи, пожалуйста, с помощью Rust (который безопасный по памяти и гонкам данных!) что этот код:
1. Действительно даёт mutual exclusion доступ к критической секции (т.е. работает корректно)
2. Является deadlock-free
3. Является starvation-free
Напиши такой мьютекс на "безопасном" зиге. Он же лучше и безопаснее раста, правда ведь?)
Давай, ты же такой крутой погромист. Ну и нас повеселишь заодно.
Так я и написал
> Так я и написалТак я тоже написал! Супер мьютекс на раст, но код я показать не могу - он секретный по заказу марсиан.
Может ты свой покажешь)?
А то балаболить и фантазировать все умеют
Пук в лужу конечно знатный, но как троллинг унылый.Ты лучше скажи так:
"Вот пример deadlock-free и starvation-free мьютекса, написанный на языке N, для которого это все доказано! Он используется в проекте М и дает ему непревзойденную надежность.
Сможете так же на Раст сделать? "А то пока это теоретическое балабольство, зато на умную книжку сослался (ты ее вообще читал?)
Тебя просят написать простой алгоритм на Раст, с доказательством корректности (20 строчек кода!!!!). Ну что может быть проще? Какая разница применяется он где-то или нет?Сам код есть (Filter lock), доказательство корректности тоже. Перепиши на безопасном Раст и покажи что Раст гарантирует корректную работу мьютекса. Но нееееет....
Типичный программист на Раст ни ... не знает ни алгоритмы, ни математику, ни многопоточное программирование, ни структуры данных, ни lock free. Вообще ничего не знает, но ходит и кричит про безопасный Раст, не разбираясь, естественно в безопасности и корректности программ тоже.
Такой, типичный Шариков. Который не может написать 20 строчек кода!!!! И показать что они будут работать корректно.
Давай я пишу на Zig и доказываю корректность,а ты на Rust и доказываешь корректность с помощью borrow checker?
> Типичный программист на Раст ни ... не знает ни алгоритмы, ни математику,
> ни многопоточное программирование, ни структуры данных, ни lock free. Вообще ничего
> не знает, но ходит и кричит про безопасный Раст, не разбираясь, естественно в безопасности и корректности программ тоже.Написал человек который даже доку не читад /_-
> Такой, типичный Шариков. Который не может написать 20 строчек кода!!!! И показать что они будут работать корректно.
Это было типа "на слабо"?
Да кто ж так троллит?! Ты просто жалок!!> Давай я пишу на Zig и доказываю корректность,а ты на Rust и доказываешь корректность с помощью borrow checker?
Хм, даже инетересно как ты корректность докажешь. Только не на бумажке, на ней и для ассемблера можно сделать. Пусть Зиг тебе ее автоматичекси выведет.
Ну давай валяй, показывай свое творение.
Если основоположник lock free алгоритмов доказывает их "на бумажке", то я буду делать также)) Наверное в безопасном коде он разбирается гораздо лучше чем 99,999999% программистов на Раст. Да и вообще любых программистов в мире.Я же не бегаю и не кричу о безопасном Zig, который избегает гонок данных, имеет безопасную работу с памятью и т.п. Вы же кричите об этом на каждом шагу.
Так покажите на практике эту безопасную работу, как она поможет в написании алгоритма в 20 строчек.
> Так покажите на практике эту безопасную работу, как она поможет в написании алгоритма в 20 строчек.Т.е просто слился? банально((
Я думал ты будешь кидать сюда куски своего кода и показывать свое превосходство над "незнакомыми анонимами в интернете", а ты только языком мести можешь(
> Я же не бегаю и не кричу о безопасном Zig, который избегает гонок данныхТы при этом сам придумал, что Раст полностью позволяет избегать гонок и докапываешься до всех "А докажите коррекность с помощью раста!!11", хотя он это не гарантирует.
Почитаей уже доку! Вот тебе цитата с Rustonomicon:
"Safe Rust guarantees an absence of data races, which are defined as:
two or more threads concurrently accessing a location of memory
one or more of them is a write
one or more of them is unsynchronized"
ВСЁ! Не больше и не меньше! (Хотя это не так мало, зигушка и в это не может...)
То что ты нафантазировал - твои личные проблемы."Data races are mostly prevented through Rust's ownership system: it's impossible to alias a mutable reference, so it's impossible to perform a data race. Interior mutability makes this more complicated, which is largely why we have the Send and Sync traits. However Rust does not prevent general race conditions."
https://doc.rust-lang.org/nomicon/races.htmlПри этом все что оно гарантирется - гарантируется автоматически!
А что не гарантируется, то можно доказать на бумажке. И будет абсолютно тоже самое.
Ну, если конечно не накосичишь в расчетах, ты же не мировое светило по мультитредингу...
Я так понимаю, все преимущества, такие как безопасность работы с памятью, zero cost абстракции, отсутствие null по сравнению с С/С++ вы игнорируете и все сводите к одному вопросу? Который, по сравнению с теми же плюсами куда проще решается на rust.С точки зрения использования абстракций, на прикладном уровне, тут rust переиспользует модель работы с памятью и следит на уровне компиляции, что если был взят, например lock, то он обязательно будет освобожден. В том же go периодически всплывают ошибки, что забыли прописать defer для лока и такое, естественно, потом дебажится в рантайме.
Rust не священный грааль, но определенный класс проблем и ошибок там отлавливается на уровне компиляции, а не в рантайме.
Как-то детальнее описывать, как компилятор помогает избегать множественного владения и облегчает написание параллельного кода не буду, потому что требует обяснить много деталей и написать много текста, чего случайные комментаторы на опеннет не достойны. Тем более что потом закончится все "а докажи теперь это все с помощью формальной верификации"
Ясно, как обычно. Когда дело доходит до конкретного вопроса или просьбы написать 20 строк кода... программисты на Раст либо съезжают с темы, либо начинают разглагольствовать про "сводите к одному вопросу".А написать 20 строк безопасного кода на Раст не могут. В принципе это всё что нужно знать про Раст, его безопасность и программистов его проповедующих.
Готов написать на Zig, ты на Раст. Я доказываю корректность кода на листочке, потому что по-другому не умею и не знаю как, ты доказываешь корректность (20 строк кода!) с помощью гарантий Раст - borrow checker, владение, типы... в общем извращайся как хочешь. Но с помощью самого компилятора.
По рукам? Или как всегда...
А давай!
Кидай сюда свой зигокод, а я кину на раст.
Наконец-то первый программист на Rust, осиливший 20 строк кода. Уважаю 💪Сейчас до компьютера дойду.
Будем писать очень простой, но корректный, мьютекс для двух статичных потоков - алгоритм Питерсона (Peterson lock).
Доказательство корректности моего кода - практически напрямую следует из доказательства в книге The Art Multiprocessing programming.
Я буду ждать доказательства на Rust на borrow checker.
То что ты сможешь написать 20 строк кода я не сомневаюсь.
> Наконец-то первый программист на Rust, осиливший 20 строк кода. Уважаю 💪Если вы не будете друг друга прикалывать, то из этого может что то получиться, что интересно почитать
> А давай!
> Кидай сюда свой зигокод, а я кину на раст.А вы мужики молодцы! (без прикола)
К шоу готов: 🍿🍿🍿
Мой вариант.
https://gist.github.com/likern/9df0d97b3551236b456716d95f282f83Жду твоего :)
> Мой вариант.
> https://gist.github.com/likern/9df0d97b3551236b456716d95f282f83https://github.com/k-walter/rads/blob/main/src/sync/peterson.rs
Не знал что под личиной русского парня скрывался K. Walter.
В интернете никто не знает что ты кот (c)
Т.е. именно по коду тебе сказать не нечего?
Не то чтобы я был сильно этому удивлен... скорее это было более чем очевидно)
Кстати заметь, ни одного unsafe.
А что я должен должен сказать по коду? Куча синтаксического шума и никаких гарантий корректности.Так вот возвращаемся к моему основному вопросу. КАК Rust гарантирует корректность этого кода и почему?
Или умный программист ВРУЧНУЮ проверил все инварианты и написал корректный код на небезопасном языке Rust? Как он мог этого сделать и на любом другом, например.
В Zig минимум синтаксического шума, и только по делу. Моя версия,на неё равняться не стоит. Это черновик. Там volatile уйдет, потому что я написал некорректный код (volatile в Java и C++ имеет разную семантику, т.к. я volatile ни разу в жизни и не использовал, наверное, естественно этого не знал. Нужен atomic чистый).
Но я это знаю, что ошибка, знаю какая и как исправить. А как в этом поможет Rust?
> А что я должен должен сказать по коду? Куча синтаксического шума и никаких гарантий корректности.Что должен? Должен проверить код.
Что можешь? А ничего ты не можешь, ты же не умеешь в раст. Мог бы скачать репу и прогнать тесты.
Тесты оно проходит
test sync::peterson::tests::race_conditions ... ok
test sync::peterson::tests::sequential_works ... ok
test sync::peterson::tests::mutual_exclusion ... ok
test result: ok. 12 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 13.88s> Так вот возвращаемся к моему основному вопросу. КАК Rust гарантирует корректность этого кода и почему?
Я тебе писал уже кучу раз в этой теме - ОТКРОЙ ДОКУ и прочитай что именно гарантирует раст.
Все что гарантируется, гарантируется автоматически.
Все что не гарантируется - доказываешь на бумажке, покрываешь тестами.> Или умный программист ВРУЧНУЮ проверил все инварианты
и написал корректный код на безопасном языке Rust. Программист молодец!
> В Zig минимум синтаксического шума, и только по делу.
А откуда ты это знаешь, если на твой код равняться не стоит? Вдруг ты что-то забыл?
В раст тоже все по делу. Вот ты написал все в кучу внутри структуры PetersonMutex, тут разделил на отдельные имплементации, чтобы код был более читабельным (но только разумеется для того, кто понимает что там написано)> Это черновик. ... я написал некорректный код ...
Черновик или нерабочий код? Если мы оба за точность терминологии, то это явно момент, который неплохо бы прояснить)))
> Но я это знаю, что ошибка, знаю какая и как исправить. А как в этом поможет Rust?
Как поможет раст исправить ошибку в Зиг коде? Даже не знаю что ответить...
В общем по существу ответить нечего.Вывод спора простой. Большинство программистов на Rust ничего сложного написать не могут, даже попытаться. Кидают чужие имплементации.
И при этом рассказывают про безопасность. Обеспечить которую они не могут, да и даже не понимают как обеспечивать.
Вывод второй. Rust даст тебе какие-то дополнительные гарантии, ну допустим, но типичный Rust программист налажает в куче других мест. В логике, в синхронизации, и т.п.
Вывод третий. Крутой программист и на Rust напишет хороший корректный код. Правда он его же и на С++ напишет, и на Zig.
> Что должен? Должен проверить код.
Что можешь? А ничего ты не можешь, ты же не умеешь в раст. Мог бы скачать репу и прогнать тесты.
Тесты оно проходитТесты написанные самим автором? Ну ты насмешил:)) Обидно что я код могу написать, а ты...или твой коллега нет?)
Ты как определил что я не могу в Rust коде разобраться?))) Сам придумал и поверил?)
> А откуда ты это знаешь, если на твой код равняться не стоит? Вдруг ты что-то забыл?
volatile убери и будет всё Ок.
> Вот ты написал все в кучу внутри структуры PetersonMutex
Ясно. Когда совсем нечего ответить начинают придираться к запятым 😄 Там не всё в кучу. Там отдельная единая имплементация.
А твои "интерфейс" это конечно ужасный говнокод. Но ты этого не знаешь. На каждый класс, наверное, пишешь интерфейсы и фабрики синглионов фабрик классов?) Да вы батенька...кодер.
Вот когда появится несколько имплементации (если, когда-нибудь...а скорее всего никогда ) то я просто в compile time проверю все функции и их сигнатуры у структуры - что есть методы lock и unlock 🔓 в структуре и всё.
> Как поможет раст исправить ошибку...
Увиливаешь. Никто не мешает использовать volatile в Rust коде и совершить такую же ошибку.
Только я знаю что ошибки могут быть и поэтому полез гуглить про volatile. А типичный программист на Rust, свято веря в безопасность, и проверки компилятора естественно никуда лезть и читать не будет. Нет warning? Значит безопасно. Компилятор всё проверил.
В итоге мой код будет лучше, качественнее, надёжнее, безопаснее чем у Rust фанатиков.
> Черновик или нерабочий код?
Рабочий я оставлю чтобы троллить на следующих новостях про Rust. Мне не к спеху поправить.
Знал что никто даже и 20 строк кода сам написать не сможет. Оказался прав 😀 Выложили бы своё - тут же поправил бы.
В общем картина Rust программистов очень печальная и удручающая
> В общем по существу ответить нечего.Т.е ты слился? Я не особо удивлен.
> Большинство программистов на Rust ничего сложного написать не могут, даже попытаться.
Я тебе предоставил чужой рабочий код на Раст, а ты мне какой-то свой багованый полуфабрикат на Zig. Представляешь, ты умудрился ошибиться в 50 строках кода! О какой квалификации вообще может идти речь...
Лучше бы нашел чужой рабочий вариант, посмотрели бы его.> Вывод второй. Rust даст тебе какие-то дополнительные гарантии, ну допустим, но типичный Rust программист налажает в куче других мест. В логике, в синхронизации, и т.п.
Феерическое предположение, на уровне "если бы бабушка была дедушкой".
Да и с чего он вдруг налажает? Ты по своему опыту судишь?
Ну не все такие программеры как ты.> Вывод третий. Крутой программист и на Rust напишет хороший корректный код. Правда он его же и на С++ напишет, и на Zig.
Причем тут с++? Там и смартпоинтеры и raii есть. Может ты с Си спутал?
Если да, то это ложное предположение. Как жаль, что таких программистов не нашлось для ядра. Хотя гугл меняет С и С++ в андроиде на раст, что показательно.> На каждый класс, наверное, пишешь интерфейсы и фабрики синглионов фабрик классов
О, ты опять показываешь свое "прекрасное" знание раста - в нем нет классов.
> я просто в compile time проверю все функции и их сигнатуры у структуры - что есть методы lock и unlock
Да, это ооочень круто. Вот только мои "интерфейсы" проверяются в compiletime)))
> А типичный программист на Rust, свято веря в безопасность, и проверки компилятора естественно никуда лезть и читать не будет.
Ты опять делаешь бредовые выводы и обобщаешь...
> В итоге мой код будет лучше, качественнее, надёжнее
Ахаха, сам себя не похвалишь - никто не похвалит)))
Может будет, а может бы будешь #ыдлокодить на тайпскрипте, кто знает...
Но пока что ты уже обделался))> Мне не к спеху поправить.
Поверь, уже его никто не ждет.
> В общем картина Rust программистов очень печальная и удручающая
Да, нам просто удручающе приходится общаться с такими как ты.
Ну у вас с логикой всё печально. Я говорю "давай напишем код" и проверим у кого больше гарантий.У меня, ручками или у Rust.Выяснилось что сам ты написать на Rust ничего не можешь. Не то что безопасно, а вообще никак.
Так об этом и речь!
Парень, ты жиденько обделался. Rust тебе не помог, а сам ты не могёшь. Как и все в этой ветке защитники. У вас только на словах всё безопасно. На деле 0 строк кода 😀 Смешно ей богу.
"Лучше бы взял", а может тогда тебя сразу на помойку выкинуть и взять того парня который тот код и написал?) Он, уверен, и на С++ без ошибок напишет.
Вам предложили написать 20 строк кода но и с этим вы не справились.
А так да, есть крутые программисты, которые пишут на Rust. Только язык тут ни при чём. Они крутые и на чистом С и на С++. С небезопасный? Берешь С++ и всё.
А так на что вы способны? Отправлять JSONчики клиенту, а всю реальную работу кто-то завал бы написал? Многопоточку там безопасную. Так хватит JS или Go за глаза.
В этом и фишка, ни одного unsafe и язык является абсолютно небезопасным. И в этом коде можно сделать ошибку где угодно. Не только логическую.Вплоть до того что поменять два условия местами и код логически такой же, а в многопоточной программе уже будет ошибка.
И почему-то "безопасный" Rust тебе об этом ничего не расскажет. И ловить ты её будешь несколько лет. И код этот очень сложный, понять где закралась ошибка будет очень сложно.
Т.е. от Сишки Rust не сильно отличается.
Возникает вопрос....и стоило ли писать этот язык с кучей ограничений, если в итоге вся эта безопасность разваливается на каждом шагу?
Может, стоило сделать просто более безопасный С, с проверкой границ массивов (а не с ограничениями) в runtime и т.п.?
И вот Rust превращается.. превращается...в Zig :))
> В этом и фишка, ни одного unsafe и язык является абсолютно небезопасным.
> И в этом коде можно сделать ошибку где угодно. Не только логическую.Не любую. А ту ошибку, отсутствие которой не гарантируется safe подмножеством.
Ну, пожалуйста, ну открой доку и прочитай!
Я тебе даже ссылку скину
doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
doc.rust-lang.org/nomicon/races.html
Надоело повторять одно и тоже!> И ловить ты её будешь несколько лет.
Неплохой наброс... Пруфов конечно не будет, да?
> Т.е. от Сишки Rust не сильно отличается.
Пхахаха. Сишка позволяет тебе сделать так:
double *ptr = (double*)malloc(sizeof(double) * 10);
double *ptr2 = ptr;
free(ptr);
free(ptr2);
И будет классический дыряшечный double-free.
А теперь повтори это в безопасном расте. Попробуй напр. в playground.> Возникает вопрос....и стоило ли писать этот язык с кучей ограничений, если в итоге вся эта безопасность разваливается на каждом шагу?
Конечно стоит. Потому что ты будет задумываться о реально сложных вещах, а рутину будет тебе подсказывать компилятор.
> Может, стоило сделать просто более безопасный С, с проверкой границ массивов (а не с ограничениями) в runtime и т.п.?
В runtime слишком дорого. Плюс там не только проверка границ массивов.
> И вот Rust превращается.. превращается...в Zig :))
Слава богу нет))
Потому что в твоем zig делаешь:
const allocator = std.heap.page_allocator;
var memory1 = try allocator.alloc(u8, 2);
var memory2 = memory1;
allocator.free(memory1);
allocator.free(memory2);
И наслаждаться "Segmentation fault at address 0x7f55bb3e5000"
Та же сишка, только в профиль. И что, помог тебе твой Zig?
Ну и как же ты не в runtime отловишь выход за границы массива?Очень хочу послушать гуру Раста, как они это делают в compile time.
Опять будете рассказывать что я там что-то не так прочитал? Товарищи, вы путаетесь в показаниях.
То вы говорите что то что Rust гарантирует... очень ограничено. А значит в compile time это не проверить (вроде это очевидно?)...а тут же на голубом глазу что runtime проверки якобы очень дороги 😀 Либо одно, либо другое.
Те в Rust просто забивают и никакие проверки не делают?
А про гарантии borrow checker Rust я прекрасно осведомлён и что он гарантирует знаю.
В моём Zig не вышла ещё версия 1.0.
И эта лишь детали имплементации, не успели ребята написать ещё эту фичу.https://github.com/ziglang/zig/issues/6004
Очевидно что аллокатор будет уметь ловить практически все известные ошибки аллокации памяти.
Включая double free.
* Detect double free, and emit stack trace of:
//! - Where it was first allocated
//! - Where it was freed the first time
//! - Where it was freed the second timeВ принципе все эти ошибки можно и нужно детектировать. И Zig это и делает. Например double lock на мьютексе из своего потока. Аллокатор тоже много чего детектирует, но не всё ещё.
И если ты говоришь что для Rust это дорого и он всё это не детектирует - получается он менее безопасный.
Ты вообще за дискуссией следишь? Ты спросил про Си
>>> Может, стоило сделать просто более безопасный С, с проверкой границ массивов
>> В runtime слишком дорого.
> Ну и как же ты не в runtime отловишь выход за границы массива?Вот ты сам придумал? что они не в рантайм. А тебе ответили "почему не добавят".
Хватит уже приписывать мне то, что я не говорил.
В си нет слайсов и итераторов, которые в расте неплохо так нивелируют рантайм проверки.> То вы говорите что то что Rust гарантирует... очень ограничено.
Нет, я такого не говорил. Это ты считаешь, что оно ограничено.
А я сказал, что раст покрывает конкретный сабсет, ошибки из которого очень распространены в системном и не только программировании и порождают море CVE.> Либо одно, либо другое.
> Те в Rust просто забивают и никакие проверки не делают?Это уже какая-то шизофрения...
> А про гарантии borrow checker Rust я прекрасно осведомлён и что он гарантирует знаю.
Ну-ну)) Ты еще в прошлой теме показал как прекрасно ты знаешь раст. И продолжаешь в этой)
> В моём Zig не вышла ещё версия 1.0.
> И эта лишь детали имплементации, не успели ребята написать ещё эту фичу.Ахахаха! Такая крохотная деталь имплементации! Вот оно чё, Михалыч!
> https://github.com/ziglang/zig/issues/6004
Висит открытая с 2020 года.
> Очевидно что аллокатор будет уметь ловить практически все известные ошибки аллокации памяти.
Абсолютно неочевидно! Может к тому моменту они проедят донаты и забросять это поделие. Или сыграет bus-factor.
Сейчас есть просто факт - это не работает в "готовом для прода" Zig'е.
> В принципе все эти ошибки можно и нужно детектировать. И Zig это и делает.Так делает или это еще не реализовано? Реализовано или "еще не всё"
> И если ты говоришь что для Rust это дорого и он всё это не детектирует - получается он менее безопасный.
Еще раз повторю - про раст я такого не сказал. Вопрос был про си, ответ был про си.
Меня восхищает твое умение додумывать вещи, которые собеседник не говорил, а потом героически их опровергать.
Про героическое додумывание - это лучше к зеркалу подойти. При чём тут вообще С?С чистым С Rust никто никогда не сравнивал. А вы всё пытаетесь спуститься пониже...на С... чтобы более выигрышно смотреться.
Мы про С++ говорили, говорим и будет говорить. И про Zig.
Про интерфейсы или как ты там их назвал в Rust - речь была про то что всё это и гораздо больше делается в Zig.
Интерфейсы это очень ограниченный инструмент. Zig позволяет это. Zig позволяет гораааздо больше. Про это речь шла.
Что такое интерфейс? Просто набор сигнатур функций который необходимо реализовать, может параметризованный.
В Zig можно сделать любые проверки всего что может быть вычислено в compile time.
Например как сделать в Rust интерфейс - у которого все методы будут начинаться с названия "start"? Или никак, или через какой-то убогий синтаксис макросов. С помощью какого-то корявого синтаксиса.
В Zig это делается легко на обычном же Zig.
Когда вас тыкаешь в Rust, где сотни критичных багов безопасности, вы почему-то начинаете кричать что это было 5 лет назад. Например что-то там с тихими переполнениями вычислений.
Однако это было не "5 лет назад", а в "стабильной production ready версии языка 1.64". Вот и вся безопасность.
Но что-то про Rust ты такого не говоришь
> Сейчас есть просто факт - это не работает в "готовом для прода" Zig'е
что это не готовая поделка 😀
Сравнивать стабильную версию языка с 64 релизами с языком 0.11, у которого уже это есть из коробки. Ну... такое, не делает чести Rust
Слайсы и итераторы это и есть runtime проверки. Но ты этого не знал. Ну что же, не удивительно.
>Куда же делись прикладные программисты, которым ехать, а не шашечки?Прикладные уже давно не пишут на С.
На С++ не так давно - но тоже редкость.
На расте писать они не будут тоже, это уже видно.Иди ко ты в топик где обсуждают Java, JS\TS, Python и прочую жесть.
Штааа? xD. Всего лишь почти все ПО по производству 3D графики написано на C++. В Blender есть и более низкоуровневый Сишный код. Unreal Engine 5 (давно не пишут xD...) написан на C++. Почти все видеоредакторы написаны на C++. Почти весь САПР - это C++. MATLAB - это C (чистый) + Java морда. Или для вас "прикладное ПО" - это для секретарей и кассиров? Так и там, особенно при отказе от винды можно запросто увидеть C++, помимо Java.
Какой же мерзкий синтаксис. Пока что самый адекватный синтаксис у конпиляемых "системных" языков - это Ada.
(Мысли вслух) Где же вас таких обучают, в каком ПТУ? Почему вам синтаксис дороже семантики?
А почему нужно обязательно налажать или в одном, или в другом? Почему бы и то, и другое не сделать нормально?
Потому что "нормально" не бывает. Синтаксис это на 90% вкусовщина. Это как выбирать компьютер по цвету системного блока. Блондиночный критерий. Синтаксис можно легко переделать (и языки с гибкой семантикой дают для этого лёгкую методу), а семантику без переписывания самого языка не переделать при всём желании.
> Синтаксис это на 90% вкусовщина.Всё что нужно знать о современных "IT специалистах" 👆
Мне кажется, вы поспешили обозвать его специалистом.
> Это как выбирать компьютер по цвету системного блока.Кстати, именно так и нужно выбирать. Лично для меня, тактильные и визуальные ощущения от устройства, гораздо важнее, чем подкапотное железо. Да и многим людям тоже, не зря у Apple столько ярых поклонников.
П.с. если что, это был sarcasm ‼
Думал сарказм, а оказалось правдой. У растоманов так бывает.
Кто не понял, поясню синтаксис - это грубо говоря набор "Literal" или "слов". Чем их количество меньше и сами слова интуитивно понятны, тем читабельность лучше. А семантика должна придавать набору ключевых слов и имён переменных общий логический смысл. И этот общий смысл слов необязательно может быть быстро понят программистом, который переходит на другой язык программирования.>Синтаксис это на 90% вкусовщина.
Согласен. Но давайте вглянем на Раст глазами чистосишника. Раст обладает развитым синтаксисом, что само по себе подразумевает мощный семантический аппарат. И всё это нагромождение "Literal" воспринимается как "наркоманский синтаксис". Если Раст учит человек никогда не программировавший, то восприятие "наркоманского синтаксиса" не будет.
Каким еще таким развитым синтаксисом обладает растишка?! У чистого Си все куда яснее.
> Синтаксис это на 90% вкусовщинаДАЛЕКО НЕ. Именно в силу синтаксиса ЛИСП (или какой-нть Брэйнфак с Перлом) канули в лету, а ПОЧТИ похожий на Си Паскакаль не выдержал битвы и... тоже забыт большинством.
Синтаксис - это не следование капризам очередного з@дp0та (как ты себе представляешь), это выверяемый годами удобный способ представления программы, ибо их не только пишут, но и ЧИТАЮТ.
Я что-то после новостей про Паскаль по нему заностальгировал. Конечно, по нынешним меркам он многословный и фигурные скобки привычнее, но все же насколько по-человечески выглядит код! И да, Ада очень близка к нему, к тому же по-настоящему безопасна.
Ada, в отличии от паскаля, может в многопоточность и асинхронность. Хотя, вроде, в fpc что-то такое есть, но оно очень сырое и не_стандартизированное.
fpc - сам себе стандарт. В стандартном Pascal даже классов нет.И кстати он (fpc) - неплох. К нему даже Lazarus сделали :)
А что конкретно не так с ним? Как такие же абстракции более лаконично и понятно описывать?Обычно, это пишут только те, кто не разобрался в языке и не писал на нем, а знает только из новостей и комментариев про то какой же ужасный синтаксис.
Ага, программист должен иметь минимум три года опыта разработки на Rust чтобы оценивать качество его синтаксиса.
Не обязательно три. Только когда начнёшь осознавать концепции и почему так сделано. Если хочется больше сахара - можно намазать макросов. Тут просто многие синтаксические вещи сделаны по-другому. И практика показывает, что плюсы начинают пытаться это повторять потому что так удобнее (типа явного self)
>Если хочется больше сахара - можно намазать макросов.У растовиков и без "сахара" - сплошной коричневый слой макросов по проектам всегда размазан. Плата за отрицательную выразительность.
Достаточно осилить rustbook, который большинство критиков синтаксиса даже не открывали дальле первой странички, чтобы большинство вопросов к синтаксису отпало
Синтаксис намного удобнее и понятнее, чем в С/С++, а больше и не нужно. Хотя немного более многословный. Преобразование через as_, макросы без прострела ноги (когда узнал про косяки макросов в Си, это фейспалм, обязательно всё в скобки, сразу вспомнил баш с кавычками).
Больше всего радует, что на волне всего этого хайпа вокруг memory safety наконец-то начали шевелится разработчики C и C++. Глядишь, наконец-то ограничат возможность прострелить себе ногу хотя бы в дефолтном окружении.
А что за "шевеления"? Особенно в контексте C интересно.
Есть proposal чтобы добавить defer. Те какие-то попытки есть.
Коммитет обсудит это лет 3-5,
потом добавят в стандарт,
через 10-15 лет попадет в ядро
Этот proposal маринутеся еще с 2020 года (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2542.pdf)
В конце 2021 вышла вторая его версия https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htmИ если бы его таки добавали, то в C23... в который он уже не попал))) И в следующий тоже.
Так что пока нет никаких предпосылок к его принятию.Вообще на уровне ядра могли бы свой самописный defer сделать. Или сделать на уровне GNU C Extensions.
>Или сделать на уровне GNU C Extensions.На уровне GNU Extensions можно много чего добавить. Например, MISRA можно было бы, -fmisra. Сразу все требования, понимаю, трудновато реализовать, но можно постепенно добавлять.
> на уровне ядра могли бы свой самописный defer сделатьв ядре есть автоматическое управление ресурсами устройств
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
>Применение "-C codegen-units=1" при сборке Android позволило снизить размер инструментария на 5.5% и увеличить его производительность на 1.8%, при этом время сборки самого инструментария увеличилось почти в два раза.Размер меньше, а время сборки медленей.
>были применены оптимизации при помощи утилиты BOLT, которые позволили довести прирост скорости сборки до 24.7%, но размер инструментария при этом вырос на 10.9%.
Размер чуть больше, а время сборки быстрее.
Хм ... не, я лучше посижу на чистой сишке.
Звучит логично.
Или программа использует меньше памяти, или работает быстрее.
Обычная задачка на оптимизацию алгоритмов.Было бы интересно услышать "гуру чистой сишки", как реализовать одновременно "быстрее и меньше памяти"
скомпилировать с -O3
А потом долго и судорожно ищешь куда бы поставить барьер, чтобы порядок выполнения был таким как ты написал, а не как захотелось компилятору.
Ну если тебе квалификации не хватает, тогда компилируй с -O2
А тем временем российские физики написали эмулятор 34 кубитного квантового компьютера именно на Rust... "Гуру" тем временем в чатиках важными холиварами были заняты
> А тем временем российские физики написали эмулятор 34 кубитного квантового компьютера именно
> на Rust... "Гуру" тем временем в чатиках важными холиварами были занятыОн так же работает как аппарат на луне, робот федор и модуль наука?
Или даже лучше?
>были применены оптимизации при помощи утилиты BOLTИ тут же рядом фанатики Раста пишут, что у них все утилиты в одном компиляторе в отличии от ненавистной им Сишки. Сравнивать они естественно будут с output ванильного компилятора Си, без сторонних оптимизаций.
Генераторы бы... с ними параллелизм в hello world будет по феншую.