Комментарии 14
Проблему с unsafe как-то решили? Дико смешно было лет 8 назад читать как они настолько сильно упоролись безопасностью что без unsafe нельзя было написать примерно никакой серьезный софт, а любые подтянутые в проект либы (разумеется unsafe) по цепочке делали и твой софт unsafe. В итоге единственное конкурентное преимущество языка его же и хоронило
Нет проблемы с unsafe - это легитимная часть языка и никто от неё избавляться не собирается. Не для всех вещей компилятор может доказать безопасность, в таких случаях используется unsafe. unsafe не делает “по цепочке” весь остальной код unsafe. unsafe код можно вызывать внутри safe кода. Обычно это небольшие небезопасные участки, обёрнутые в безопасное api.
Вообще говоря safe/unsafe это маркетинговый ход нежели технические подробности. Язык должен предоставить какое-либо число, чтобы это измерить. Например, в случае гонки - какие объекты пытаются обратиться к шаре, проблема чтение-модификация-запись при статическом анализе, теоретическая глубина стека при рекурсии или измеренная в реалтайм, сведения о динамических аллокаторах особенно в многопоточке, может даже что-то связанное с DMA, то есть если язык не поддерживает такого рода числа - то это сомнительное преимущество по сравнению с явным указанием флажков, счётчиков ссылок, дополнительных состояний объекта итд. Да это неудобно, но зато прозрачно и позволяет выявить при дебаге всевозможные комбинации. Тем более как только появляется FFI/mmap особенно в ембедде - даже на одном таком пороге ломается вся концепция. По сути язык стал обвязкой вокруг некоего memory and object manager. Но что-то явных преимуществ нет. То есть универсальная попытка встать между компиляцией и интерпретацией скорее всего тупиковая.
Нет проблемы с unsafe - это легитимная часть языка и никто от неё избавляться не собирается
Т.е. язык как был мертворожденным, так им и остался
Я не пишу ничего не Rust, но так уж вышло, что более или менее его знаю.
В чем проблема с unsafe? Ничего страшного в unsafe нет)
В сущности, это просто маркер мест в коде, которые могут покорраптить память и просто упрощают отладку этого класса проблем.
Почти любой unsafe можно спрятать за safe API, просто обеспечив гарантию инвариантов, делающих unsafe - безопасным) Это же главная задача и смысл unsafe блоков)
Проблема главная и немаловажная - нет стандарта по которому можно получить гарантированные компиляторы. Это же касается и Питона. Версии 2.7 и 3 стали именем нарицательным. Выйдет Rust 2.0 вот и придётся думать что там нужно прогнать через Perl/Python Regexp-ом чтобы починить кодовую базу. Думается что с LLM актуальность не стандартизированных языков существенно снизилась, потому как для работы нужны предсказуемые инструменты а не синтаксический сахар, который уже LLM инкапсулирует до уровня отсутствия в нём необходимости, включая покрытие тестами и технический регламент (саммари). Вообщем останется только Python и K&R C или Страуструп С++ образца начала 90-х, включая диалекты близкие к синтаксису Java/OpenCL(MP)/CUDA, благодаря феноменальной наработанной кодовой базе по существу (может даже ещё Fortran), а не трансляторами Java/Python/C++ -> Rust. Да, Go/Ruby/Rust и др современные, но их начало совпало как раз с этими кодогенераторами, вообщем те языки разработка которых пришлась где-то на 2015-20й год скорее всего будут свёрнуты, так как датасетов для претренинга от них маловато, они достаточно далеки от железа и имеют коммьюнити с минимальной поддержкой, язык нужно учить, развивать и делать это промышленным способом а не энтузиазмом разработчиков.
Rust обещает полную совместимость внутри edition
Это лучше чем ломающие изменения питон и лучше чем дряхлый C++
А вообще, несёте херню
Rust обещает полную совместимость
Разработчики языка могут этим заниматься сколько угодно, может появится 3 ветки языка Rust% какой-нибудь. Важно то, что дряхлые плюсы всё-таки имеют ISO/IEC 14882, это позволяет исключить бардак с инструментами и библиотеками. Во всяком случае можно апеллировать к документу уровня ГОСТ, описывающему язык. У Питона с этим тоже беда, но он по крайней мере стал BASIC-ом 21го века благодаря грамматике, умещающейся на тетрадный лист. Любой Bison/Flex влезит в контекст даже самой захудалой LLM-ки, это его очень хорошо вытаскивает + Pip-ы на все случаи жизни. Раст не может похвастать таким коммьюнити, так как язык скорее нишевый чем общего назначения. Если для Питона или того же Perl есть pip и Cpan, то что ищется для Раста с первой же строчки поисковика? Что там нужно набрать "rust library modules", "rust library hub" (по иронии попадаем сюда), "rust modules library collection"... все пути ведут к git. Язык без поддержки порталом по скачиванию чего угодно минуя заклинания git встроенными средствами - это путь к забвению. Мне охота высветить что-то на выводы малины нолики-единички. Куда обратиться кроме частных лиц (обратите внимание - автор свернул проект в архив)? Для питонов делаю в один клик. Для С коммьюнити куда больше так как там вся обвязка и есть "протухший" С. Тем более можно забыть что LLM уже генерит на С даже для эмбеда и микроконтроллеров-восьмибиток, там причёсывание из разряда поправить порядок инициализации перифирии и пару бит. Нашёл тут как-то либу на Раст для энкодера полнорегистровую, заставил LLM переписать на С, чтобы управлять скудной памятью самостоятельно, ESP32 это из пушки по воробьям. Прекрасно получилось хоть для атмелки хоть для кортекса м0/3.
апеллировать к документу уровня ГОСТ, описывающему язык
Не пойму к чему вы
Вот проявится у Rust второй компилятор тогда может и понадобится что-то вроде ГОСТ
Да и неопределенное поведение в c++ штука неприятная при наличии всех типа ГОСТ
rust library modules
https://crates.io/
Craits.io - такое ощущение что это запрятано от всех поисковиков, а если более точно то https://crates.io/. Я захожу на главный портал языка https://rust-lang.org/ - и собственно где ссылка на это? Захожу сюда https://rust-lang.org/community/ - где этот кратэс... или разработчики его сами боятся. Я нашёл его только в https://rust-lang.org/tools/ мелким шрифтом где-то в глубине фрейма. Вообщем отношение такое к пользователю из разряда вот мы тут что-то придумали хорошее, но то, как это хорошо использовать - додумывайте сами. В плюсах и сях неопределённое поведение уже давным давно решается определёнными вставками. Любой санитайзер выловит любые утечки, зато это можно записать для любой платформы начиная от Спектрумов до ПЛИС-ов. Тем более с LLM-кой которая качественно обёртывает тестами своё творчество контроль за памятью уже не проблема как год или даже полтора.
Что касается ГОСТ-а на язык коим является ISO/IEC на протяжении уже треть века или даже половины уже - то это гарантия что в энтерпрайзе есть что брать за основу не вдаваясь в подробности реализации - если соответствует - действуй. Это позволяет избежать vendor-lock или привязки к мыслям что будет со второй версией чего-то там. Комитет - это некая письменная захардкоженная гарантия результата. Разработчики же не могут дать такую бумагу. Только некие протоколы тестирования в частном порядке согласно каким-то там внутренним регламентам. Сегодня там есть этот прогер/архитектор, завтра женился, ушёл в Тибет, забил, стало душно, не интересно итд. Вот чтобы этого избежать и придуманы стандарты, фиксирующие в определённый момент времени то то необходимо. Горизонт планирования разработки без стандартов - вчера и сегодня. То есть для хобби и экспериментов. Поэтому Линус совершенно прав, пуская новые языки и фреймворки в ядро только на альтеративные функции, во всяком случае дубляж на стандартном языке имеется точно. Либо уже в комитете лежит драфт, но что-то сомнительно, хотя может и пришло время.
То, к какому аду приводит стандарт хорошо видно на примере C++. Буквально на днях выяснилось, что контейнер, запланированный в новом стандарте, будет в 2 раза медленнее аналогичного контейнера в буст. А история с std::views::please_work, ой простите std::views::as_input, без которого std::views::filter тотально сломан? Это всё оттуда же идёт, от стандартизации и комитета.
Стандартизация C++ — это не благо, а вынужденная мера из-за расплодившихся несовместимых реализаций. Rust идёт по пути референсного компилятора, это гораздо лучше. А к чему приводит искусственная стандартизация при наличии референсного компилятора известно на примере Haskell: всем плевать на стандарт и все пишут код конкретно для GHC.
Rust также хорош для моделирования предметной области, наравне со scala. Но мне почему-то никто не верит.
В целом article получилась not bad, по сложности affordable для junior developers, хотя порой не хватает details. Думаю, Rust вполне может стать timeless, как C++

Rust: зачем он появился, что умеет и почему компании переписывают на него части своих систем