Comments 48
Проблему с 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.
будет в 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 также хорош для моделирования предметной области, наравне со 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 - пойдёт.
в него случайных значков типа !, ?, &, ' и прочую 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 и всё такое).
Синтаксис как синтаксис. Через неделю ежедневной писанины глаза адаптируются, и ты начинаешь читать эту разметку на полном автомате
Позвольте несколько вопросов про 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" обычно позволяет не заниматься подобными извращениями. Для примеров можно посмотреть как например происходит работа с файловыми дескрипторами или сокетами - там обычно приходится их доимплементировать.
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.
Очередная статья о том, как раст спасет мир, вылечит рак и заставит Маска написать идеальный мессенджер
Жаль только что компилироваться весь этот праздник будет до второго пришествия)
Rust: зачем он появился, что умеет и почему компании переписывают на него части своих систем