Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 71
Проблему с 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 блоков)
Ансейф изолируется в маленьких модулях под капотом библиотек. Тебе в прикладном коде вообще не нужно трогать его руками
Так же смешно читать начало создания C/C++. Дополнительно:
Rust - unsafe блоки кода
C/C++ - 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-кой которая качественно обёртывает тестами своё творчество контроль за памятью уже не проблема как год или даже полтора.
где этот кратэс. или разработчики его сами боятся
Первая же ссылка на "главном портале" ведет на страницу документации "The Rust Programming Language", подразумевая что взрослый человек, который решил изучать новый язык программирования, не будет тыкаться как слепой котенок по "порталу" и поисковикам, а откроет официальный учебник по языку и прочитает ее. В главе 14 мы видим
So far, we’ve used only the most basic features of Cargo to build, run, and test our code, but it can do a lot more. In this chapter, we’ll discuss some of its other, more advanced features to show you how to do the following:
https://doc.rust-lang.org/book/ch14-00-more-about-cargo.html
Более того, взрослый человек еще обычно в состоянии открыть документацию на toolchain, который он использует. Что же мы видим на первой странице документации утилиты "cargo":
Cargo is the Rust package manager. Cargo downloads your Rust package’s dependencies, compiles your packages, makes distributable packages, and uploads them to crates.io, the Rust community’s package registry. You can contribute to this book on GitHub.
https://doc.rust-lang.org/cargo/
Так что и от кого тут спрятали?
В главе 14 мы видим
То есть то, что является основой для студентов и школьников, где они могут почерпнуть различные новые штуки, сделать приложение приложением где-то посредине учебника. Это должно быть в первом разделе, вернее даже в первых строках - что у нас настолько хорошая инфраструктура, "что мы начинаем с нашей базы знаний, где собраны скрипты-либы со всего мира, это поможет Вам разобрать все примеры и использовать готовые источники для реализации любых проектов"
Так что и от кого тут спрятали?
На основном портале языка необходимо догадываться где искать хаб с библиотеками? Я захожу на Perl - вижу CPAN, на Python - PyPl сходу. На первый взгляд Cargo - это какой-то диалект вроде Raku для Perl.
Вообщем невнимательное отношение к пользователю в мелочах. А раз на мелочи нет времени (и средств), что вполне очевидно, то это означает, что сейчас просто снимаются сливки за счёт остатков старожил, как это происходит с некогда взлетевшим Delphi, компании передаются из рук в руки, разработка уходит куда-то в какие-то ниши (похоже закончится всё панелями операторов и SCADA, но там уже LabView подъест довольно хорошо, так как язык сопровождается стандартами и аппаратурой), но на общее применение уже рассчитывать не приходится.
Язык не хороший, не плохой, он другой и взлетел с опозданием благодаря энтузиастам. Тем более необходимо тратить время на изучение (даже не обучение - его нет среди вырванных кусков примеров). Без стандартизации его могут не принять на полномасштабный претренинг LLM, а без этого сейчас уже практически никуда, каждый год уже наверное за 5 лет идёт. Плюс устаревшая инфраструктура по сборке, особенно отладке из середины 90-х похожая на CMake. Про debug ни одного слова в разделах инструкции! Так вот в этом у Rust провал с таким отношением к пользователю, но это простительно, потому как скорее всего нет столько средств для полномасштабной поддержки. Cargo-механизмы практически главное, это как часть языка, но они упоминаются лишь как командная строка. Как я этот карго могу затолкать в имеющиеся системы сборки итд, как прикрутить автоматизацию.
Сейчас язык - не основное, важна инфраструктура и коммьюнити вокруг него. Все эти фишки уже никого не интересуют, тем более что сейчас уже более менее развился многоязыковый подход, даже поддерживаемый IDE. Если что необходимо сделать быстро и прототип - Python, ближе к железу - C/С++ и его диалекты, посчитать формулы - Maxima/Matlab, для дремучих CAD - AutoLisp, файлодробилка - make или bash, для всего остального - кодогенерация и мета-языки сделанные по месту. Какая ещё документация на toolchain? Опять лезть в man-ы в 21м веке? Даже для дремучего С все эти флажки автоматизировали до уровня локального поисковика, по С++ есть и интерактивные и RAG/MCP/векторные с прикруткой к агентам, да, для раста это тоже есть но какие-то единичные проекты.
Все вопросы которые должны быть первые они в на последних страницах. Как запустить как отладить, где скачать, где пример по ошибке компилятора, как исправить, и всё это без костылей и поиска копипастом или ссылками на Рэдит или Соурсфорж. Язык попытался объять необъятное с сомнительным штучным преимуществом. Колоссальная работа, но получился Вавилон. Решение вопросов не должно перекладываться на пользователей. Ну и наличие микса safe-unsafe 50/50 как-то несколько подавляет впечатление о преимуществах, то есть пользователь должен заранее это предполагать, то есть помогать компилятору, обычно наоборот.
Вообще говоря специально потратил тут карму чтобы в большей мере уяснить, что политика Хабра - не очень соответствует дискуссионной. Писать только то что хотят прочитать и комментировать только то что не вызывает сомнений. Скатится рано или поздно всё в унылость, уже обратил внимание что самые кармистые обычно избегают диалогов в режиме объективного (!) спора, в котором рождается истина, и прибегают к игре в поддавки.
Тут как раз много о чём можно подискутировать. Вот моя точка зрения. Я учил программирование в Политехе больше тридцати лет назад начав с Фортрана и затем Паскаль. Эти два языка были стандартны для двух семестров. В основном численные методы (это был физтех), всякие Рунге-Кутта на Фортране да "Жизнь" Конвея на Паскале. Затем в лаборатории Физтеха я нашёл компилятор Си на ДВК и взял в библиотеке Кернигана и Ричи. Я читал эту книгу взахлёб, это было офигенно после Паскаля и я написал программу для дифрактометра на Си (и ассемблере MACRO-11), это было реально круто, я открывал всё новые стороны языка и железки, сидел по ночам в лаборатории, меня было за уши не оттащить от компьютера. Это начало девяностых где-то. Си++ мне "не зашёл", я честно взял Страуструпа в читальном зале, и эта книга "вынесла мне мозг", зато я "потрогал" Модулу-2 и Оберон, и это было хорошо, свежая струя после Паскаля. Так уж получилось, что я не стал физиком, а стал программистом и в коммерческой разработке ваял на Дельфи, потом на LabVIEW (это меняет сознание) и на Си да Ассемблере. За это всё неплохо платят.
Я всегда интересовался другими языками, особенно функциональными (Scala, Erlang, Haskell) чисто для кругозора, Раст "зашёл" со второй попытки, когда я наконец "вкурил" его основы. Он заметно отличается от Си идеологически, хоть и позиционируется как замена. Но теперь меня не оттащить от Раста, как когда-то от Си. Только Си образца девяностых по сравнению с Растом 2024 года прост как пять копеек, так что количество моих "открытий" тут зашкаливает. Что-то нравится, что-то не очень, но это те же ощущения, что от Си, только ня порядок мощнее.
Хорошая литература важна, я бы бесусловно порекомендовал The Rust Programming Language, при этом именно третье, последнее издание, она только что вышла:
И мне ещё понравились немецкие книжки, я их случайно в местной библиотеке взял (да, я тот динозавр, что ходит в городскую библиотеку), та, что поменьше, повторяет предыдущее издание Клабника, а вот та, что побольше свежая и хорошо его дополняет (на немецком мне проще, я больше 25 лет живу в Германии), два месяца я их читал:
Что б вы понимали масштаб бедствия — у меня в библиотеке почти полсотни книжек по Расту:
И в каждой есть свои "зёрна". Я это всё к тому, что "орешек знанья твёрд, но всё же мы не привыкли отступать..."
Ну а что касается прикладных фишек, вот смотрите — мы в соседней статье упражнялись в изучении особенностей статической линковки С++, вы, вроде, там тоже были. Я изучал зависимости собранных файлов и в какой то момент меня инструмент, которым я обычно пользовался (на .net) подзадолбал, так что я открыл терминал, набрал там cargo new r-depend... Затем сходил в копилот и попросил его набросать код, который взял бы DLL или исполняемый файл и показал бы зависимости, он выдал это, двадцать строчек кода:
use pelite::pe64::*;
use std::{env, error::Error, fs, path::Path};
fn main() -> Result<(), Box<dyn Error>> {
let path = env::args().nth(1)
.ok_or("Usage: dep_viewer <path_to_exe_or_dll>")?;
let data = fs::read(Path::new(&path))?;
let pe = PeFile::from_bytes(&data)?;
let imports = pe.imports()?;
println!("Dependencies for {}:", path);
for import in imports {
println!(" {}", import.dll_name()?);
}
Ok(())
}Теперь осталось cargo add pelite — тут используется крейт PeLite и следом собираем cargo build -r и наступает счастье:
>r-depend.exe r-depend.exe
Dependencies for r-depend.exe:
api-ms-win-core-synch-l1-2-0.dll
KERNEL32.dll
ntdll.dll
VCRUNTIME140.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dllВесь процесс занял пару минут, и это в общем неплохо. В общем всё норм и с инфраструктурой и коммьюнити вокруг него... Что же касается крейтов, то копилот иногда заносит в старые версии, там бывает чехарда несовместимостей, всё как обычно, но для этого есть голова и руки.
Спасибо за такой прекрасный ответ! А то уже подумалось что сообщество Rust несколько токсично и не дружелюбно по отношению к пользователям. Ведь предстоит самое главное для любого новичка или профессионала - это потратить время на изучение с целью это потом как-то применить с учётом раскрывающихся возможностей и не разочароваться. Тем более для коммерческого использования всё должно быть в лучшем виде.
Тут даже дело не в том какой язык хороший/плохой а на какие задачи его можно без проблем применить. В этом плане все прошли такой же путь, он в то время был примерно +- одинаковый для всех, тогда языки претерпевали становление. Как говорится много званных да мало избранных. Java, PHP, Perl, Python, C/C++ итд итп но в итоге коммерция взяла верх в плане удобства использования, необходимое количество литературы, особенно той что онлайн. Сейчас даже не знаю тех кто для практики использует бумажную - она издаётся как минимум с опозданием на 1-2 года по отношению к нововведениям или исправлениям багов, что актуально для больших проектов. Даже не с точки зрения языка а поддержки его окружением. Время уже ушло такого рода изданий, тем более это скорее описание-инструкция нежели какие-либо фундаментальные основы. Например лежит толстенная книга из разряда MS-DOS 6.22 /Widows 3.11 для рабочих групп и всё обо всём, но актуальность... с другой стороны rkf45 Фортрана - это классика.
Изучение IDE, инструментов, системы сборки, как что куда ткнуть где логин-пароль, апи ключ, уже превалирует над изучением синтаксиса. Подавляющее большинство времени учащиеся тратят на то куда ткнуть, какую команду сделать, где какие файлы-папки, потом необходимо разложить алгоритм и приблизить его к языку, произвести анализ данных, проводить эксперименты и чтобы это было быстро и сразу с кучей примеров под рукой. По этой причине с Perl незаметно перешёл на Python, так как многое начало предаваться забвению и стало неудобным.
Для языка важна не его незыблемость а скорость изменений, нововведений, релизы IDE, удобство их использования, теперь уже и LLM, наличие стандарта языка, его спецификация, всевозможные инструменты для работы с кодом, включая рефакторинг, онлайн-сервисы а-ля Юпитер, невысокая цена входного билета по изучению, прорваться языку в школьную/университетсткую программу - это вообще говоря достижение. Раньше этим мог похвастать Basic в 80-е, Pascal в 90-е, в некоторых даже были C/Java в нулевые и Python в десятые, сейчас же он повсеместно. Помимо самого языка надо изучить: git, make, pip, shell - это серьёзный довесок и если язык идёт с этим перпендикулярно, это дополнительная нагрузка.
Что в расте хорошо на первый взгляд: обёртка тестами, карго и safe. Вроде бы и всё. Что плохо: перегруженный синтаксис и сопоставимая информационная ёмкость с обычными плюсами, для эмбеда linker-секции это бодание с safe нежели решение задачи. Также абсолютно непрозрачные механизмы рекурсии, многопоточки, того же менеджера памяти. Сколько он съест, каково быстродействие, есть ли кеш, есть ли shared-memory, потокобезопасные очереди. По запросу в поисковик "Thread safe on Rust" какой-то блог от 2015 года. По запросу с заменой на Python что то с пометкой 15 hours ago... причём на портале самого языка.
То есть у разработчиков языка относительно слабое преимущество и нет прорыва в поисковики, индексаторы, различного рода базы знаний наподобие MSDN, пока что это только карго с пакетами, причём пользователю дополнительно нужно разгребать зависимости особенно для всяких микроконтроллерных штуковин. Проблема очевидная - нет человеко-часов на примеры, документацию, спецификацию, оформления языка и приведение его в тот формат который можно назвать стандартом, одними донатами и опенсорс-энтузиастами сыт не будешь. Нужны коммерческие заказы а не плагин-курсач из карго или что-то для гаража наспех накиданное.
Поэтому, по-хорошему необходимы какие то выдающиеся, явные примеры которые создают инфраструктуру и нишу для языка.
Например как Ардуина выстрелила в своё время так как взяла а основу С и сделали простейшую, милейшую IDE, которая стала подсобкой для любой лабы.
Тот же LabView уже чуть ли не промышленный стандарт для осциллографов с центнер весом и измерительных центров.
LISP - это Автокад (не знаю кто пользует, но что-то пробовали) а также описание алгоритмов-данных наряду с JSON, системы символьных вычислений Maxima например, эксперименты по кодогенерации.
Delphi где-то крутится в панелях операторов до сих пор, в основном поддержка легаси пока есть те кто помнят Паскаль.
Matlab+Simulink и его клоны - в моделировании.
C/C++ - операционные системы и всё подряд, тут без комментариев, накопленный объём - готовый датасет хоть для AGI.
Python - эксперименты, железки среднего уровня, прототипирование, школьное изучение, аналогично Basic, который де-факто стандарт как VB-скрипт всяких офисов.
HDL-языки само собой отдельная ниша, и то есть System C. Всякие GPU - Nvidia уже припаивают ARM-ядра с собственным Линкусом, им до x86 уже никаких дел нет, CUDA - диалект С как и OpenCL, для многопроцессорных такой же OpenMP.
PHP/Java/JS - Web, тут своя кухня, знания, навыки, наработки сложившиеся на протяжении трети века.
SQL/ да тот же 1С - бизнес процессы, может даже и КОБОЛ туда из экзотики
Fortran - для совсем уж суровых моделей и числодробилок, IFC например плюс поддержка академической среды
Остаётся тот самый 1%, где бьются между собой Go/Ruby/Rust/Perl.
Пока что явная ниша для языка не видна. Было бы интересно если бы он предоставлял какие-то очень весомые плюшки для эмбеда, контроль за регистрами периферии, всякие инициализаторы чтобы не забыть, чтобы была нативная поддержка проверки следования какого-либо разбросанного кода, более удобная работа с макросами как с переменными, потому как если #-!пестрит в коде то каких-то преимуществ по сравнению с настройками в С полувековой давности как бы и нет, тем более в С можно имена генерить на этапе компиляции с конкатенацией ##, в Расте же use paste::paste - это какой-то довесок с ограничениями. То есть язык не готов быть machine-generated в полной мере с автоматическим синтаксическим разбором. И по-хорошему для завоза в IDE нативным образом вот это надо содержать в более актуальном состоянии
Как говорили великие "единственный способ изучить новый язык программирования — это начать писать на нём программы". В настоящий момент я просто делаю "пробные пристрелки" на внутренних некоммерческих проектах, в основном десктоп приложения с математикой, используя разные GUI библиотеки. Иногда прототипирую что-то на LabVIEW или в MATLAB, а потом перекладываю на Раст. На прошлой неделе сделал вот приложение для захвата изображения с рентгеновского детектора, с сохранением картинок. Я б и на LabVIEW сделал, но там была функция обратного вызова, Раст позволил обойтись без библиотеки-помощника, сделал и отладил всё за полдня. В основном использую RustRover. В общем надо просто начать и границы применимости постепенно очертятся.
То есть то, что является основой для студентов и школьников
Нет, пакетный менеджер не является основой для школьников при изучении языка, это чушь.
На основном портале языка необходимо догадываться где искать хаб с библиотекам
Не надо доказываться, надо открыть учебник и по нему идти. Или воспользоваться гуглом. Или открыть документанкцию. Впрочем, судя по тому, что вы с удивлением только тут узнать о пакетах карго, у вас даже до hello world на расте не дошло.
На первый взгляд Cargo - это какой-то диалект
На первый взгляд кого? Может это ваша такая особенность, не надо проецировать ее на других.
сейчас просто снимаются сливки за счёт остатков старожил
Какие сливки, каких сторожил? Грейдон Хор ушел из из раста более 10 лет назад, о чем речь?
как это происходит с некогда взлетевшим Delphi
Причем тут делфи? Что за шизофазия началась?
Без стандартизации его могут не принять на полномасштабный претренинг LLM
Все существующие модели прекрасно пишут код на раст, какое еще не включение в претренинг?
Cargo-механизмы практически главное, это как часть языка
Нет, cargo это не часть языка, это тулчейн.
Как запустить как отладить, где скачать, где пример по ошибке компилятора
Все это есть в документации. Ну или если вы из-за вашего состояния не можете концетрироваться на чтении, спросить любую LLM, она вам тоже ответит.
Сейчас язык - не основное, важна инфраструктура и коммьюнити вокруг него. Все эти фишки уже никого не интересуют
Какого не интересуют? Кафедру в МПСУ? Ну ее может быть и не интересует, а крупнейшие IT компании, от cloudflare до амазона внедряют у себя раст.
Язык попытался объять необъятное
Нет, язык этого не пытался, это вранье
с сомнительным штучным преимуществом.
Уж не человеку, который не осилил прочитать документацию на язык, оценивать тут преимущества и недостатки.
Колоссальная работа, но получился Вавилон
Нет, получился хороший новый системный язык.
Ну и наличие микса safe-unsafe 50/50 как-то несколько подавляет впечатление о преимуществах
Только с точки зрения человека, который не понимает что такое safe и unsafe. Что не удивительно если вы даже не дошли до hello world.
Вообще говоря специально потратил тут карму
А этот абзац к чему? Всем глубоко плевать на вашу карму, вы поплакаться тут решили что-то ли, пожалейку включить?
режиме объективного (!) спора, в котором рождается истина
Какая еще рождающаяся истина в публичном споре? Вам 12 лет что ли? Вы первый раз в жизни в интернет зашли?
Что касается ГОСТ-а на язык коим является ISO/IEC на протяжении уже треть века или даже половины уже - то это гарантия что в энтерпрайзе есть что брать за основу не вдаваясь в подробности реализации - если соответствует - действуй. Это позволяет избежать vendor-lock или привязки к мыслям что будет со второй версией чего-то там. Комитет - это некая письменная захардкоженная гарантия результата. Разработчики же не могут дать такую бумагу. Только некие протоколы тестирования в частном порядке согласно каким-то там внутренним регламентам. Сегодня там есть этот прогер/архитектор, завтра женился, ушёл в Тибет, забил, стало душно, не интересно итд. Вот чтобы этого избежать и придуманы стандарты, фиксирующие в определённый момент времени то то необходимо. Горизонт планирования разработки без стандартов - вчера и сегодня. То есть для хобби и экспериментов. Поэтому Линус совершенно прав, пуская новые языки и фреймворки в ядро только на альтеративные функции, во всяком случае дубляж на стандартном языке имеется точно. Либо уже в комитете лежит драфт, но что-то сомнительно, хотя может и пришло время.
То, к какому аду приводит стандарт хорошо видно на примере C++. Буквально на днях выяснилось, что контейнер, запланированный в новом стандарте, будет в 2 раза медленнее аналогичного контейнера в буст. А история с std::views::please_work, ой простите std::views::as_input, без которого std::views::filter тотально сломан? Это всё оттуда же идёт, от стандартизации и комитета.
Стандартизация C++ — это не благо, а вынужденная мера из-за расплодившихся несовместимых реализаций. Rust идёт по пути референсного компилятора, это гораздо лучше. А к чему приводит искусственная стандартизация при наличии референсного компилятора известно на примере Haskell: всем плевать на стандарт и все пишут код конкретно для GHC.
будет в 2 раза медленнее
Это не проблема стандарта. Если он будет в 2 раза надёжнее, проще в восприятии, реализовывать необходимый функционал с заданной степенью защит, быстрее компилироваться, не иметь проблем с совместимостью - то пожалуйста.
Допустим владелец энтерпрайза по претренингу LLM, берёт у трудящихся датасеты. Один прогон - это квартал непрерывных обсчётов и порядка 1.5 мегабаксов (есть даже техотчёт DeepSeek где это прямо указано на arXiv-е). И тут выбегают фреймворки и языки и говорят давайте мы ещё туда включим свои поделки, которые мы завтра вычеркнем если что пойдёт не так. Ну и что делать? Лучше взять датасеты подготовленные в соответствии с тем, что потенциально ещё будет использоваться 3-5+ лет, чем то, что могут сломать уже завтра до нуля. Потом будут все хаять модели, мол, они, дурные такие, не понимают мой запрос и генерируют глюки. RAG/MCP должен помогать шлифовать свежее а не реализовывать основной функционал. Причём каждая итерация претренинга для улучшения требует кратного увеличения затрат. Так что скорее всего сейчас подведут черту под всеми не стандартными фишками и закроют этот убегающий вагон.
Простите, но чем стандарт С++ принципиально отличается от editiions в rust? Стандарты С++ тоже несовместимы между собой - часть библитечного кода или семантики меняется. Есть множество историй, как больно происходит переход с условного С++14 на С++20.
При этом стандарт очень тяжек к изменениям, благодаря чему мы имеем кучу костылей в виде vector, регекспов и прочих перелестей.
Плюс компиляторы ведут себя иногда по разному, даже при наличии единого стандарта. Каких-то фич не хватает, какие-то могут немного отличаться, плюс не забываем о расширениях компиляторов, которыми тоже пользуются
Проблемы исполнителей как говорится шерифа не интересуют. Стандарт - это то на что может опереться энтерпрайз принимая решения. Там до кода никакого дела нет. Особенно сейчас когда качественные, human made датасеты для претренингов очень дороги. Именно там основные человеко-часы. Официально, я могу запросить то, что editiions соответствуют каким-то фиксам специфиации? Вообще где спецификация на язык. Кто может поставить под ней подпись что этот компилер оттестирован, прошёл соответствующие тесты итд. Как я это могу применить в какой-нибудь серьёзный эмбед если будет ответ в виде "эксперт под ником FunAnonym15342 на нашей площадке провёл тест и показал 100% что всё работает, исходники выложил на гит и результаты тоже". Пока что сходу видно вот это и вот это. То есть это некая декларация, мануал по использованию, затравка для Bison/Flex в виде файла грамматики но никак не спецификация. Тем более с отсылкой на нормативы вроде ISO/IEC 25010 и прочая и прочая как здесь например. То есть там совершенно гигантский объём работ - и именно этот документ и есть язык программирования а не компилятор к нему, по сути инфраструктура Rust крутится вокруг него безотносительно к внешним ограничениям. Даже если есть опенсоурс компилятор всегда можно его протестировать на соответствие стандартам любой организацией и по результатам собственно принять работу. На основе чего тестировать Rust? На общих основаниях? Какую версию брать за основу. То есть в этом плане проще взять дуболомный но стандартный язык, чем то что поддерживается по сути группой энтузиастов на донатах, сегодня они есть завтра скажут - мы идём в LLM с ISO, и всё на этом.
Вот проявится у Rust второй компилятор тогда может и понадобится что-то вроде ГОСТ
Ferrous System уже ведёт работу по стандартизации по крайней мере некоторого сабсета языка. Ну и стоило попросить человека посмотреть дату появления языков С и С++ и появления их официального междунардного стандарта.
Важно то, что дряхлые плюсы всё-таки имеют ISO/IEC 14882, это позволяет исключить бардак с инструментами и библиотеками.
Это шутка что-ли? Именно С++ хорошо известен тем, что там полный разброд во всех направлениях. Недавно видео вышло от опытного разработчика на полтора часа, где фактически только проблемы разброда и обсуждаются. Раст просто на два порядка круче в плане и инструментов и библиотек (не количества, а простоты работы).
Это проблема тех кто синхронизирует доки компилятора со Стандартом. Сам Стандарт заданной практически исключает какой-либо разброд. Там проблема уже в культуре реализации с той и с другой стороны. Вообще говоря очень мало прогеров которые в принципе хотя бы по диагонали смотрели в Стандарт, обычно сразу во флажки компилера, всякие git-хаболабы с примерами, инструкции из форумов и прочие сугубо прикладные выкрутасы. Потом оказывается что документ описывает всё не так как кто-то когда-то прочитал в man или доках или скопипастил сосед. Компилятор, в котором есть соответствие нормативам обычно лишён каких-либо выкрутасов. UB это для каких-то совсем вопиющих случаев. Тем более что есть и gcc, и intel и расширения Nvidia nvcc и прочая и прочая - есть выбор, это кстати также преимущество. Rust может повторить судьбу Delphi на этой почве несмотря на Open Source в отличие от этой пропиретарки. Крайний и, скорее, последний стандарт Паскаля был в 1993м, это уже очень далеко.
несете херню, потому что ни один разработчик в здравом уме не станет писать на Rust то, что можно сделать на C++ (который, кстати, не стоит на месте и развивается, а по скорости превосходит в 2 раза все его "клоны")
Rust также хорош для моделирования предметной области, наравне со scala. Но мне почему-то никто не верит.
В целом article получилась not bad, по сложности affordable для junior developers, хотя порой не хватает details. Думаю, Rust вполне может стать timeless, как C++
Ну наконец-то нормальная статья про назначение rust, а не нейрослоп из рекламного булшита. Добавил в закладки, чтобы просто бросить ссылку, если кто-то начнёт у меня спрашивать для чего нужен раст
PS: я бы дополнил статью ссылками на полезные проекты, которые написаны на раст
В недостатки стОит добавить местами вырвиглазный синтаксис. Как будто кто-то взял нормальный текст и рандомно накидал в него случайных значков типа !, ?, &, ' и прочую mutь.
Ну т.е. разработчики изначально говорили, что сил хватает только на эффективную реализацию, но не нормальный синтаксис и "девелопер экспириенс". Так и получилось.
В любом случае, в языке много банальной неконсистентности. Почему Result и Option пишутся целиком, а fn, mut и Err сокращённо? Зачем вообще нужно объявлять тип Result в качестве возвращаемого функцией? Это должно быть просто на уровне ABI...
Всё вместе даёт такой запах гаражного поделия. Может и интересно, но тащить такое в прод и инвестировать своё время не хочется.
Как будто кто-то взял нормальный текст и рандомно накидал в него случайных значков типа !, ?, &, ’ и прочую mutь
На это часто жалуются новички, но…это ведь не понятно только для тех кто язык не знает, если ты язнык знаешь, то это для тебя не “случайные символы”. Я разве что могу понять претензию к тому что символ легко глазами пропустить. Я бы например предпочёл использовать not как в python вместо !. Ну и непонятна ваша претензия к ! и & - они в куче языком используются точно в том же смысле что и в расте (для отрицания и для взятия ссылки)
Зачем вообще нужно объявлять тип Result в качестве возвращаемого функцией?
Имхо, это скорее плюс, что это точно такой же енам, как все остальные енамы, а не магия компилятора. Даёт свободу выбора - хочешь используй стандартный Result, хочешь, что-нибудь своё
Про ! имелось ввиду println! - зачем выделять макросы отдельно кроме как для удобства разработчиков компиляторов? Это грубая ошибка дизайна.
В большинстве языков обходятся без & для указания ссылок; в этом случае амперсанд можно было бы использовать вместо mut. Тоже косяк в пользу компилятора
зачем выделять макросы отдельно
Чтобы разработчик знал что он вызывает макрос, а не обычную функцию. Учитывая что язык условно низкоуровневый, полезно это знать - когда просто фанкш кол, а когда синтаксическая магия. Вот как раз Си, где вызов дефайнов такой же как обычной функции, мне меньше нравится. Но может это вкусовщина, хз.
в этом случае амперсанд можно было бы использовать вместо mut
Не понял ваш посыл. &x и &mut x это два разных типа ссылок. И это отдельные типы от x и mut x.
да, всё верно, ! и не равно != сбивают без подсветки синтаксиса. Синтаксис должен помогать а не вносить неясности, тем более это то ради чего язык собственно и учат. Там не должно быть преимуществ реализации компилятора - в первую очередь - удобство для пользователя. Тому же Perl простительно всюду $ и @ с %, но сразу зато видно - где скаляр а где контейнер а где хеш. Синтаксически язык перегружен, причём, операторы слишком общие и неоднозначно трактуются. Конечно, синтаксис разработан так чтобы можно было сделать single line inliner в отличие от Питона например где табуляция с энтером редактором в принципе отображается как следующая строка. Но опять-таки, это чем-то должно быть лучше плюсов, шарпов, той же Javы или банального Питона. Функционально они имеют всё что нужно.
всё верно, язык выглядит просто как надстройка над неким сгенерированным по шаблону менеджером памяти и многопоточности. Подход был нормальный, когда Страуструп С++ изначально сделал как обёртку на K&R С, просто транслировав на этот язык синтаксис и далее запускал С компилятор. Но это 80-е прошлого века и получилось весьма удачно так как изменения гармонично вписались в С инфраструктуру.
Достаточно посмотреть ключевой момент сюда. Делаем классическое AST и отправляем его... в gcc или в llvm через промежуточное представление MIR. По крайней мере на первый взгляд выглядит как-то так. Проблема safe решается кодогенерацией по шаблонам. По крайней мере похвально, то что язык компилирует сам себя, то есть является self-hosted. Однако... где в сырцах компилятора те самые фишки самого языка, которые отличают его не то что от С++ даже от С, визуально выглядит как Pascal обёрнутый вместо begin-end фигурными скобками с возможностью LISP прятать в [] и (). То есть информационная ёмкость как была так и осталась примерно одинаковая со "старым"и языками. Главное преимущество будет это safe (не очевидное в эпоху LLM) или какие-то хитрости из разряда regexp в Perl, которые часть самого языка и он идеален для обработки текста, но это ниша. Похоже что единственный стандарт это что то вроде Unsafe Extern Blocks RFC (RFC 3484), причём каждая такая внешняя заглушка может ломать любое преимущество. Вообщем кодогенерация по шаблонам не есть какое-то существенное превосходство в чём-то, особенно когда оно неуправляемо затягивает различные менеджеры не свойственные прямой компиляции. Напоминает helloworld.exe объёмом в 50 килобайт под DOS супротив helloworld.com в сотню байт. Тут есть свои + и -, но когда речь идёт о языке общего назначения, это должно всё быть под контролем и настраиваемым
Если сравнивать Rust с С++ (чьи проблемы он в основном и решает), то сравнение синтаксиса явно не в пользу конкурентов. Только за счет смены модификаторов по умолчанию (все const по умолчанию, move вместо копирования и т.д.) синтаксис становится проще и код читабельнее.
Зачем вообще нужно объявлять тип Result в качестве возвращаемого функцией Потому что мы можем реализовать другой Result под задачу. Это часть библиотеки, а не прибито гвоздями
Потому что мы можем реализовать другой Result под задачу. Это часть библиотеки, а не прибито гвоздями
Это глупость и чисто С++way, где у вас на каждый чих есть 5 несовместимых способов реализации, начиная с указателей, массивов и строк. И всё это ради легаси и мифической ситуации, когда кто-то напишет свой супер-дупер аллокатор с перегрузкой операторов * и ,
Конкретно возврат значения из функции это часть calling convention. И раз уж оно заведомо не совместимо с С (например, там внутре могут быть указатели со значением 7), почему бы не внести полноценный Result в этот самый cc. Тем более, в языке без исключений, но с возвратом ошибок, где он будет использоваться примерно всегда. Условно, постановить, что на амд64 результат (если есть) возвращается в RAX, ошибка (если есть) — в RDX или там REX. Любители написать свой Result идут развлекаться с диспетчеризацией, трейтами, несовместимостью со стандартной библиотекой куда-нибудь ещё, например в плюсы.
Конкретно возврат значения из функции это часть calling convention. И раз уж оно заведомо не совместимо с С (например, там внутре могут быть указатели со значением 7), почему бы не внести полноценный Result в этот самый cc.
Вообще это то, что мне очень нравится в Расте после LabVIEW. Там есть такое понятие как DataFlow, и виртуальные инструменты "нанизаны" на кластер ошибки (это такой design pattern), и вот в Расте оно примерно также устроено, типа:
use anyhow::{Result, Context, anyhow};
fn step1() -> Result<i32> {
Ok(10)
}
fn step2(x: i32) -> Result<i32> {
Ok(x + 5)
}
fn step3(x: i32) -> Result<i32> {
if x > 20 {
Err(anyhow!("Value too big"))
} else {
Ok(x * 2)
}
}
fn workflow() -> Result<i32> {
let a = step1().context("step1 failed")?;
let b = step2(a).context("step2 failed")?;
let c = step3(b).context("step3 failed")?;
Ok(c)
}
fn main() {
match workflow() {
Ok(_) => println!("Success"),
Err(e) => println!("Error: {:#}", e), // pretty print with chain
}
}Тут можно ещё "идиоматичнее" сделать, но даже так очень норм, как по мне, новичку.
Для языка общего назначения такое нанизывание - ну это так себе, особенно если есть ограничения по стеку, плюс ещё что там происходит с типами данных на этой почве. Язык позиционирует себя safe, но это не должно быть дорогим удовольствием. Тем более не говоря уже о точках восстановления в таких исключениях. Для простейшей замены switch-case - пойдёт.
Чем меньше магии, тем лучше. Тот же Паскаль не в последнюю очередь проиграл, потому что содержал функции с переменным числом аргументов, но не давал программисту возможность делать свои такие функции.
Особый подход в возврату ошибок как в Zig нужен, если нет других, более базовых механизмов, чтобы это выразить. В Rust такой механизм есть, поэтому магия не требуется.
в него случайных значков типа !, ?, &, ' и прочую mutь.
ну, так в сях/плюсах оно и того хуже да ещё и неявно. В Rust вырвиглаз обычно появляется, когда там какие-нибудь trait bound описываются, но не представляю как можно было бы выражаться проще. Другие зумерские языки тоже не сказать чтобы лучше.
Почему Result и Option пишутся целиком, а fn, mut и Err сокращённо?
ну fn и mut это ключевые слова и хорошо, что их не стали делать как в каком-нибудь JS с его function или Java c кучей public static final . А если опять же сравнивать с плюсами, то там как и в си есть и const enum и mutable explicit - тоже получается не очень консистентно и длинно. Ну а Result/Option и Err это названия классов/полей и называть можно как угодно. Учитывая что Err почти всегда с собой несёт какие-нибудь данные об ошибке не слишком полезная для этого сигнатура типа должна быть покороче имхо. Можно написать собственную библиотеку ошибок, по аналогии anyhow или thiserror, и назвать типы как вам хочется- хоть плюсами прикиньтесь с его std::expected и std::optional. А вообще вроде как опциональные типы калькированы из того же OCaml, на котором писались первые версии компилятора, и, скорее всего, они в таком виде оттуда перекочевали. Возвращаясь к миру си - есть же всякие errno и прочие - тоже сокращенные по целому ряду причин - надо перечислять?
Всё вместе даёт такой запах гаражного поделия.
да чтоб все такие поделия творили. Если это гаражные поделия, то поделия уровня макинтошей в гаражное время джобса. Вообще интересно с чем вы сравниваете это поделие, что оно вызывает такие ощущения.
проблема в балансе семантики синтаксиса. public static final можно сделать PSF и далее перед компиляцией просто развёртывать это дело питоном (утрированно). Любое ключевое слово переключает стейт-машину компилятора - это упрощает реализацию языка, но ломает глаза разработчика. изобилие повторяющихся элементов вроде let особенно если есть правило назад (а-ля goto) довольно утомительно. С в этом плане более чем сбалансирован - повторяющиеся элементы по сути математика как и должно быть. Переменные объявил - и далее как угодно. Питон вообще где поставил табуляцию там и область видимости после двоеточия. То есть в Расте с этим какая-то недоработка, необходимо соблюдать определённый ритуал со скобками, а значит, должна быть Раст-совместимая IDE, которая генерит это удобство. Наподобие мучений в VDHL с этими самыми => в инстансах-entity элементов. Но там это простительно так как это другой класс языков и можно это нагенерить из схемы. Нет конечно можно if let Some(stmt) = self.basic_blocks[from].statements.first_mut() стрелять в пятку делая = вместе с == в if, но опять-таки синтаксис должен помогать а не вносить дополнительную нагрузку. Тем более _ и .. крайне неудобно читать - это или точки или пробел или ещё что. Когда пиксель был в полэкрана в разрешении 640 на 480 на 13'' дисплее это было супер, когда же мониторы почти уже 4к, нужно иметь микроскоп. На Питоне этот символ может быть любым, здесь же это синтаксис.
Раст-совместимая IDE
Для этого собственно и придумали LSP, который прикручивается к любой IDE имеющей с ними работать. Поддержку языковых серверов и формата завезли ещё до релиза 1.0.
С VHDL не работал, но по гугловому примеру напоминает работа со стримами в с++ а ля std::cout << "asd"; std::cin >> y; . Мозолит глаза, но вроде семантически понятно - в какую сторону стрелки, туда и текут данные.
стрелять в пятку делая = вместе с ==
да не знаю как там можно стрельнуть - компилятор сам расскажет, где косяк. Да и благодаря семантике подобные конструкции бесплатно разносятся на отдельные выражения. В while циклах не очень удобно, в остальном вообще никаких проблем делать
let item = self
.basic_blocks[from]
.statements
.first_mut();
if let Some(el) = item { /*...*/ };И совершенно неважно было ли там обращение к членам или цепочка вызовов filter/map/fold.
когда же мониторы почти уже 4к, нужно иметь микроскоп.
казалось бы многие редакторы уже давно умеют увеличивать размер шрифта, чтобы не ломать глаза. Не очень понимаю вашу боль в этом плане. Ну а void-синтаксис можно избегать, чтобы не страдать. Без накладных расходов. Да и в Rust можно использовать любой символ для этого как и в Python и даже заткнуть ворнинг про неиспользуемые переменные одной директивой.
должна быть Раст-совместимая IDE
Ну RustRover от JetBrains вроде норм. Ресурсов, конечно, жрёт как не в себя, и мог бы быть порезвее, но там много чего именно под Раст заточено (cargo и всё такое).
neovim, helix, vscode, zed - все прекрасно работают с LSP и, кроме vscode, не слишком затратны по ресурсам в сравнении с любым жидбрейнсом. По крайней мере не сталкивался с ситуацией, когда бы мне этого не хватило, но у меня проекты в среднем не сильно сложные, хотя немного работал с исходниками zed в самом zed. В vim-like редакторы правда не пробовал дебаггер прикручивать для ржавчины.
Синтаксис как синтаксис. Через неделю ежедневной писанины глаза адаптируются, и ты начинаешь читать эту разметку на полном автомате
Потому что раст идёт от ветки языка ML, а java и C++ от B. То, что вы не знаете синтакс ML, ocaml, Haskell и прочее, это не проблема этих языков, а только вашего узкого кругозора.
Проблема в том, что когда эти языки создавались, каждый создавал клавиатуру для себя лично, используя ЭПСН-25, или как он у них там в Калифорнии назывался. Отсюда и синтаксис. Взгляните на предлагаемые клавиатуры и 80-х, по разнообразию они покроют любой авторынок нынешний. Это сейчас всё свелось +- к стандартному варианту который уже у миллиардов лежит. А тогда := - это один клик, { - открывается } с забоем итд чуть ли на уровне скан-кодов. Поэтому синтаксис - это дело наживное, а вот как он встроен в язык - это вопрос, и не в пользу языка как выясняется, предикаты очень тяжело читать, их оформление это отдельное искусство.
Кому тяжело читать предикаты? Где выяснисось что не в пользу языка? Причем тут ЭПСН-25 если раскладка qwerty идет еще со времен печатных машинок. Что за бредятина.
Вот вам RK-P400C из 80-х, на подумать.
А, ну если набивать т. наз. диграфами и триграфами когда??< { тогда норм. Речь о том что тогда каждый производитель давал функциональные клавиши на свой вкус и цвет. IBM одно Microsoft другое HP третье итд каждый боролся за удобство использования конкретного железа. Поэтому вполне возможно что были клавиатуры для Паскалей-Хаскелей и С с наличием клавиш := , ^= и прочие - где то мелькало фото с такой. Там скан-код сразу подставлял 2 символа вместо одного. Не зря же эти диграфы придумали, чтобы писать на клавиатурах которые не поддерживают {} и прочие скобки не входящие в 7-ми битный набор.
Позвольте несколько вопросов про rust (пытаюсь понять, стоит его изучать или ну-нафик? Сам пишу на Си и C++ и некоторые подходы языка вызывают вопросы):
= Как-то по типу можно можно узнать, что он с владением или нет? Например, преобразуем пример из статьи в такой вид:
let string1 = ...
let string2 = string1;
// println!("{}", string1); // ошибка компиляциив string1 присваивается тип (как результат функции или др.), который меняется от всего подряд: настроек компилятора, флагов, дефайнов и др. Например, присвоение в string1 он может быть в одном случае String, в другом i32. Можно ли заранее проверить в коде, будет ошибка компиляции на println или нет (типа sfinae в плюсах)? Или подмены типов (универсальные библиотеки и т.п.) так не работают?
= Result<T, E> это гвоздями приколоченный синтаксис на уровне языка? Или можно создать свой SemiResult<T, S, E>, который присваивать Err("blah-blah"), Ok("good"), Semi("so-so") (и как-то указать, что Semi это ещё и автоматический выход из функции)? И в продолжение вопроса: про оператор ? - его функционал высечен в граните (на наличие второго типа выходим из функции) или можно как-то "подрихтовать"? Обработать несколько типов или выходить по наличию первого типа?
= Есть ли офлайновый вариант работы, без подкачки всякого? Т.е. какой-то комплект компилятора/библиотек/др - собрали-установили, и оно НЕ МЕНЯЕТСЯ? В нашем продакшене очень желательна стабильность: 5 лет назад собрали приложение - выдали в работу (на некотором оборудовании/окружении); сейчас нашли багу в-том-самом-старом-коде; её исправили - и нужно собрать на том же самом окружении, что было 5 лет назад (и должно работать на том самом оборудовании/окружении);
= Какое-то подобие пользовательского деструктора? Например, есть некая структура, к ней приколочен файл (открыт дескриптор). Хочется при разрушении структуры в файле дописывать данные перед закрытием (например в заголовке обновлять размер и контрольную сумму)? Смотрю примеры на rust и с деструкторами как-то не балуются.
Можно ли заранее проверить в коде, будет ошибка компиляции на println или нет
Присваивание всегда передаёт владение. То есть владеет ресурсом тот, кому последнему его присвоили. Чтобы в приведённом примере владение не передавалось можно взять ссылку (что не передаёт владение) или сделать глубокую копию (что создаёт новый ресурс и берёт владение над ним).
let string2 = &string1; // ссылка
// ...
let string2 = string1.clone(); // копия
Или можно создать свой SemiResult<T, S, E>
Да, можно. Result это такой же енам как все остальные, пользоваться им не обязательно. Разве что да, к нему приделан синтаксический сахар в виде ?. По сути
fallible_call()?;
это то же самое что
if let Err(e) = fallible_call() {
return Err(e.into());
}
можно рассматривать это так. То есть возвращает ошибку выше, с возможность конвертации в ваш тип ошибки (если вы такое реализовали).
Есть ли офлайновый вариант работы, без подкачки всякого
Библиотеки можно подключать локально по указанию пути, можно разместить в вашем приватном репозитории и указать ссылку - как вам удобнее. Со стабильностью всё ок.
Какое-то подобие пользовательского деструктора?
Есть. Для типа можно имплементировать трейт Drop. Как раз ваш пример с файлом можно сделать. На нём построено многое в стандартной библиотеке - освобождение памяти, мьютексов и тд https://doc.rust-lang.org/std/ops/trait.Drop.html
Ну по первым двум вопросам проще всего сослаться на третью/четвёртую и девятую главы The Rust Programming Language - там как раз про заимствование и владение и обработку ошибок. Вообще именно это "переломный" момент при переходе с Си на Раст, если его "прочувствовать", то потом всё относительно несложно.
По поводу оффлайнового режима - есть cargo-vendor, как раз для этого — все зависимости будут сложены в ваш проект в папку vendor.
А пользовательский деструктор - drop и RAII ваше всё.
Как-то по типу можно можно узнать, что он с владением или нет?
В Rust по-умолчанию действует move семантика, а не как в плюсах copy by default. Аналогичным образом по-умолчанию переменные неизменяемые, а любые изменяемые работают по принципу "многие читают, один пишет". Всё проверяется на этапе компиляции - тот самый механизм проверки заимствований. Компилятор сам расскажет, где заимствоваание может приводить к проблемам и даже покажет места "откуда были удары".
Result<T, E> это гвоздями приколоченный синтаксис на уровне языка?
В стандартной библиотеке они прибиты. Но ничто не мешает написать собственный тип. Многие используют крейты thiserror и anyhow для более приятной работы с ошибками. Под капотом там уже настроена конвертация в нужные типы из стандартных. Вы также можете написать конвертацию через реализацию некоторых трейтов типа Into<T> или From<T> и работа будет довольно бесшовной. Ну а работа с таким типом там максимально приятная:
match semi_result {
Ok(msg) => println!("gratz, you got {msg}"),
Semi(msg) => println!("better luck next time with {msg}"),
Err(msg) => println!("well, shiiiiii. its {msg}"),
};
// ну или если прикрутите монадический интерфейс
semi_result
.then(|msg| println!("gratz, you got {msg}"))
.well_then(|msg|println!("better luck next time with {msg}"))
.map_err(|err|println!("well, shiiiiii. its {err}"));Есть ли офлайновый вариант работы, без подкачки всякого?
если есть собственный registry то можно и с ним работать. Либо указывать для своих зависимостей собственные же репозитории где-нибудь на корпоративных серверах. По-умолчанию cargo смотрит в публичный регистри на crates.io. Есть lock файлы, позволяющие фиксировать версии зависимостей для герметичных сборок, есть инфраструктура для кэширования зависимостей, аудита и верификации этих зависимостей и много чего ещё связаанного с безопасностью и воспроизводимостью сборки. Обычно всё прячется за какой-нибудь одной командой в cargo. В плане CI/CD это просто огромная отдушина в сравнении с тем что есть у плюсов. Если за 5 лет фиксы не потребовали бампа версии компилятора, то проблем не возникнет. Собственно с какого-то момента ментейнеры крейтов внедрили политику MSRV - minimal supported rust version. То есть если версия компилятора позволяет использовать фичи конкретного крейта, то можно не обновлять версию. Обратная совместимость у Rust обещается существовать всегда вплоть до 1.0 версии.
Какое-то подобие пользовательского деструктора
под капотом компилятор дешугарит уничтожение объекта, как вызов obj.drop(), так что если имплементировать трейт Drop, то поведение можно расширять. Аналогичная история с перегрузкой операторов да и вообще любым поведением - имплементация соотвествующих трейтов. Не балуются обычно за ненадобностью - идеология "make invalid states unrepresentable" обычно позволяет не заниматься подобными извращениями. Для примеров можно посмотреть как например происходит работа с файловыми дескрипторами или сокетами - там обычно приходится их доимплементировать.
в вашем коде при принтлн владение после создания перешло в стринг2, чтобы владение осталось можно сделать клон или передать ссылку, в настройки компилятора первое время советую не лезть на момент знакомства с языком, первое время пальцы и мышление должны привыкнуть к подходу кодинга на Расте, другими словами просто решайте задачки на Расте первое время.
можно определить свою сигнатуру обработки ошибок, про ? не смотрел, но в документации наверняка о нём есть описания.
по поводу офлайна, скачиваю rustup, в данный момент у меня окно, математика и gl с минимальными зависимостями(без зависимостей в прямом понимании слова зависимости, там зависимости только под биндген), они оформлены библиотеками lib.rs, чтобы избавиться от bindgen вам придётся писать этот функционал с нуля, если у вас задача консервация и цель только компилятор.
пользовательский деструктор это определение
pub fn calc() {
let test_line: Vec<&str> = "1 / 20".trim().split_whitespace().collect();
let mut count = 0; // 1 2 3 4
for (i, o) in test_line.iter().enumerate() {
if *o == "+" || *o == "-" || *o == "*" || *o == "/" {
if *o == "+" {
count = 1;
} else if *o == "-" {
count = 2;
} else if *o == "*" {
count = 3;
} else if *o == "/" {
count = 4;
}
let temp_res1 = &test_line[0..i].to_vec();
let temp_res2 = &test_line[i + 1..].to_vec();
let op1 = temp_res1.get(0).expect("l").parse::<f32>().expect("msg");
let op2 = temp_res2.get(0).expect("l").parse::<f32>().expect("msg");
let res: f32 = match count {
1 => op1 + op2,
2 => op1 - op2,
3 => op1 * op2,
4 => op1 / op2,
_ => -1.0,
};
println!("{:?} {:?} {:?}", op1, op2, res);
}
}
}
...
struct MyError {
mes: String,
code: i32,
}
impl fmt::Display for MyError {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
write!(f, "Error {}: {}", self.code, self.mes)
}
}
fn do_something() -> Result<(), MyError> {
Err(MyError {
mes: String::from("Something went wrong"),
code: "anynumber",
})
}
...
impl<'a> Drop for Cube<'a> {
fn drop(&mut self) {
self.gl.delete_vertex_arrays(1, &self.vao);
self.gl.delete_buffers(1, &self.vbo);
self.gl.delete_buffers(1, &self.ebo);
self.gl.delete_textures(1, &self.texture);
}
}
...
impl Drop for Object {
fn drop(&mut self) {
дропаем владения структуры под именем Object
}
}
...
предположим у нас есть такое
#[derive(Debug, Clone)]
pub struct GlWindow<'a> {
display: &'a XDisplay,
window: sys::Window,
gl_context: sys::GLXContext,
colormap: sys::Colormap,
}
тогда чтобы была цепочка вызовов над текущим владением
pub trait GlDebugExt: Sized {
fn display_version_debug(self) -> Self;
}
impl GlDebugExt for GlWindow<'_> {
fn display_version_debug(self) -> Self {
unsafe {
// Используем стандартные вызовы OpenGL через ваши биндинги
let version = sys::glGetString(sys::GL_VERSION);
let renderer = sys::glGetString(sys::GL_RENDERER);
let vendor = sys::glGetString(sys::GL_VENDOR);
if !version.is_null() {
let v_str = std::ffi::CStr::from_ptr(version as *const i8);
let r_str = std::ffi::CStr::from_ptr(renderer as *const i8);
let ven_str = std::ffi::CStr::from_ptr(vendor as *const i8);
println!("--- OpenGL Debug Info ---");
println!("Vendor: {}", ven_str.to_string_lossy());
println!("Renderer: {}", r_str.to_string_lossy());
println!("Version: {}", v_str.to_string_lossy());
println!("-------------------------");
}
}
// Возвращаем объект обратно, чтобы цепочка не прервалась
self
}
}
...
и можно будет вызвать через цепочку
в момент создания по цепочке дебаг вывод
let window = GlWindow::new(аргументы)
.expect("Не удалось открыть window")
.display_version_debug();temp.md вот задачки потыкайте, тут по нарастающей в целом изи и изящно выходит
Rust помогает писать многопоточный код безопаснее.
А можно подробнее? Автоматизация atomic семафоров?
Как человек пишущий на С/С++ 11 я честно не вижу смысла в Rust по крайней мере потому что в С++11 (умные указатели + почти любой стат анализатор) ловит все перечисленные в статье проблемы. Единственная проблема у С++, лично у меня - это что каждый новый стандарт добавляет ряд вещей которые иногда радикально усложняют понимание кода ради экономии строчек. Еще иногда попытки обмануть компилятор "С" ради ускорения оборачиваются большой потерей времени из-за того, что разработчики компилятора уже придумали как ускорить исходный честный вариант.
Ну наверное если совсем примитивно и "в лоб", то вот если вы на С++ напрограммируете состояние гонки, типа такого, то компилятор даже не чихнёт:
#include <thread>
int counter = 0;
void increment() {
for (int i = 0; i < 1000; i++) {
counter++;
}
}
int main() {
std::thread t1(increment);
std::thread t2(increment);
t1.join();
t2.join();
std::cout << "Counter: " << counter << std::endl;
return 0;
}А вот на Расте оно не скомпилируется
use std::thread;
static mut counter:i32 = 0;
fn increment() {
for _ in 0..1000 {
counter += 1;
}
}
fn main() {
let t1 = thread::spawn(|| {
increment();
});
let t2 = thread::spawn(|| {
increment();
});
t1.join().unwrap();
t2.join().unwrap();
println!("Сounter: {}", counter );
}и он заставит вас вкорячить unsafe, и тогда вы сами себе злобный Буратино, либо использовать мьютекс и лок, как положено
В Rust mutex - контейнер:
let data: Mutex<i32> = Mutex::new(0);
let mut num: MutexGuard<i32> = data.lock().unwrap();
// компилятор не позволит сохранить ссылку на i32, так чтобы
// она пережила Mutex или MutexGuard
// MutextGuard - смартпоинтер, при выходе со скоупа автоматически снимает локТакже система типов позволяет описать "потокобезопасность" типов:
// многопоточный оператор for_each на итераторе принимает замыкание, которое
// обязано захватывать переменные с окружения исключительно по
// "константной ссылке", а также может быть безопасно смувлено в другой поток
// или безопасно переданно по ссылке в другой поток
// все эти инварианты проверяет компилятор и все это описано в сигнатуре ф-ции
fn for_each(&mut self, closure: F) where F: Fn(Self::Item) + Sync + Send {
// ....
}очти любой стат анализатор
из open source, то бишь бесплатных у плюсов считай только cppcheck и есть. За остальные надо башлять. Прочая инфраструктура работает только как DAST (asan, tsan, ubsan и прочие), то есть нужно писать очень много тестов для покрытия, чтобы действительно отлавливать то, что ржавый компилятор разрешает на этапе компиляции. Новые фишки языка - типа концептов и контрактов - конечно помогут, но ещё не скоро ибо их вот только-только стандартизировали и толком ещё не приняли на вооружение. Но это и стандарт надо до C++20 поднимать как минимум. Для вариантов use-after-free или double-free статических решений не существует в принципе. Я конечно видел как чуваки пытались Lifetime на шаблонах скрафтить, но пользоваться этим крайне неудобно, да и идея была скорее для хаба "ненормальное программирование", нежели как production ready решение.
А можно подробнее? Автоматизация atomic семафоров?
скорее расскажет, где вы мьютекс забыли на пошаренных данных взвести. А если оно не пошаренное как надо - но использованное в другом потоке то и в это укажет мол заверните в mutex или arc.
Еще иногда попытки обмануть компилятор "С" ради ускорения оборачиваются большой потерей времени из-за того
как-то так и ждём нормальных модулей в С++. Тем временем у Rust они уже из коробки и без горожения килобайтных описаний порядка компиляции оных в Cmake.
Как человек пишущий на C++17 и выше, в десктоп разработке я бы наоборот был бы рад перейти на Rust, особенно если бы на нём был Qt, который мне нравится даже не столько гуёвиной, сколько системной событий и кучей метаобъектных наворотов. Мне просто надоело уже делать отдельный полный прогон с asan, tsan и иногда ubsan, ну не могу я работать в парадигме "не падает и нормально". Вот на контроллерах да, там я за редким исключением заперт в рамках C99 потому что в безопасных системах это стандарт за счёт простоты. Да и тех болячек которые решает rust на контроллерах у меня прям ну совсем мало на фоне всего остального, да и отлаженные наработки не хотелось бы трогать.
бинды к qt уже есть. Там же до кучи можно ещё и на Gtk посмотреть. Ну а если брать нативные ржавые - система собыий обычно либо уже есть, либо прикручиватеся с полпинка при помощи каких-нибудь std::sync::mpsc.
Я конечно не пробовал, только ознакомился, но что-то мне подсказывает что с полпинка там не получится. Раст полагается на свой рантайм, qt на свой, и попытка их подружить ни к чему хорошему не приведёт как мне кажется. Ровно как и пытаться сделать что-то за пределами QML, я как-то привык всё вручную делать. Да и до гибкости Qt в плане сигнал/слотов крейтам из раст вроде как далеко, как раз из-за гарантий безопасности. Мне Qt нравится именно своей экосистемой, что мне не надо тащить 100500 либ на каждый чих, тут тебе и gui, и периферия, и мощная система событий. Может это конечно профдеформация из-за работы с зависимостями в C++, даже при том что я использую vcpkg, но мне не особо нравится когда открываешь маленький проект, а там штук 50 зависимостей из которых автор использует одну функцию. Хотя когда из-за пары функций boost тянут тоже прикол отдельный.
Очередная статья о том, как раст спасет мир, вылечит рак и заставит Маска написать идеальный мессенджер
Жаль только что компилироваться весь этот праздник будет до второго пришествия)
Я недавно с удивлением обнаружил, что Rust используется в качестве языка для написания смарт-контрактов в блокчейне Stellar. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Rust: зачем он появился, что умеет и почему компании переписывают на него части своих систем