Rust и rust staging branch в чем разница
Зачем нужен Staging Branch в Rust
Сегодня мы обсудим, что такое Staging branch в Rust и зачем оно нам нужно. Я люблю разбираться в сущности англоязычных понятий, обращаясь к их, пускай даже дословному переводу. Этот случай не является исключением. Гугл транслэйт предлагает такую версию перевода: постановочная ветка. Чтобы было проще понять, изменим первое слово на «промежуточная». Так всё намного ясней, не правда ли?
Иными словами, скачав Staging branch, вы сможете увидеть этапы разработки новшеств, внедрение которых планируется в основную игру. Так, например, было с электричеством.
Если вы смотрите флэша на YouTube, то знайте: последние его видео сняты именно на промежуточной ветке. Сначала разработчики добавили провода и генераторы с переключателями. Спустя несколько дней появились нажимные плиты и лазерные датчики. Потом внедрили полноценный арсенал для построения логических электро-цепей.
Аналогичную ситуацию можно было наблюдать и с воздушным шаром. Сперва появилась его текстура на промежуточной ветке. После он начал взлетать при появлении. И, наконец, завершилось всё появлением полноценной системы управления этим транспортным средством.
Таким образом, Staging branch в Rust нужен для того, чтобы вы могли оценить то, как и над чем проходит работа у Facepunch. Ветку внедрили примерно год назад. При этом была предполагалось, что игроки будут комментировать на официальном сайте, что стоит оставить, а от чего избавиться.
Так как владение английским языком в России не очень популярно, то мы узнаём обо всём, что происходит на промежуточной ветке, от таких людей, как флэш. Они нам, условно говоря, переводят слова разработчиков.
Кроме того, Staging branch – это отличная возможность для новичков ознакомиться с тем, как устроена игра без лишних нервов. В своё время я, научившись добывать ресурсы, выколотил их гору, а пока учился прятать их и строить дома, меня убили несколько раз, и я всё потерял. На промежуточной ветке можно играть одному, следовательно, таких неприятностей, как у меня, происходить не будет.
Чего не стоит делать в Rust, если начали играть в 2021 году
Rust – это необычный симулятор выживания, который привлек к себе внимание огромное количество геймеров. При этом новички часто думают, что в этом проекте нет ничего сложного, и уже с самого начала делают все то, что и в других играх с элементами выживания.
К сожалению, Rust не отличается особым гостеприимством по отношению к новым игрокам, поэтому стартовать бывает довольно сложно. Перед вами подборка главных ошибок, которые делают новички, решившие поиграть в Rust в 2021 году.
Одному будет тяжело
Rust – далеко не самая лучшая многопользовательская игра для одного человека. Здесь есть несколько этапов развития, и добраться до каждого из них можно только за счет продолжительного гринда. Если играть в команде со своими друзьями, то вы гораздо быстрее достигните цели, чем в одиночку.
Также стоит отметить, что 99% других игроков не дадут вам мирно существовать в виртуальном мире игры. Вам постоянно придется отбиваться от обезумивших «дикарей», которые захотят отобрать ваши вещи и ресурсы. Естественно, ни у одного новичка не получится защитить себя от оравы более опытных игроков, поэтому лучше изначально залетать в Rust хотя бы с парой друзей.
Никому нельзя верить
Этот пункт частично противоречит предыдущему, но при этом он еще более важен. Прежде всего вам стоит забыть о том, что взаимодействие с другими игроками в многопользовательских проектах – это норма. Rust вообще не та игра, где нужно объединяться с незнакомыми людьми, чтобы вместе получить больше лута или ресурсов. Здесь вы можете рассчитывать только на себя, и если начнете доверять первому встречному игроку, то очень скоро поймете, почему этого нельзя делать. Особенно это касается товарищей с хорошей экипировкой, которых вы встретите на своем пути.
Дело в том, что в Rust каждый играет сам за себя, а опытные игроки очень часто обманывают новичков самыми разными способами. Незнакомец, который предложит побегать с ним по виртуальному миру и при этом будет носить броню заметно лучше вашей, скорей всего грифер. Это такой игрок, который при первой же удобной возможности просто вас убьет и заберет все вещи. Так что, начиная играть в Rust, никому не доверяйте!
Курс юного строителя
Если вы вдруг не знали, то в Rust есть строительство, и здесь оно играет довольно важную роль. При этом данная механика имеет ряд особенностей, которые придется изучить в самом начале знакомства с игрой, иначе ваши архитектурные «шедевры» будут попросту разваливаться, а вы впустую потратите ценные ресурсы.
Прежде всего стоит отметить, что у каждого строительного блока есть мягкая и твердая сторона. Во время строительства блок всегда нужно устанавливать таким образом, чтобы твердая сторона находилась снаружи будущего здания. Если не соблюдать это правило и размещать материалы как попало, то вашу постройку сможет развалить первый попавшийся игрок, причем с помощью обычного топора или кирки. Согласитесь, будет не очень приятно наблюдать за тем, как несколько часов ваших трудов кто-то разбирает по кирпичикам за считаные минуты.
Все вещи в одном месте
Огромное количество игроков в Rust вообще не уделяют время крафту. Они считают, что гораздо проще украсть готовые предметы у других пользователей, чем стоять у станка и пытаться что-то сделать. Именно поэтому в этой игре противопоказано хранить все свои вещи в одном месте.
Ни в коем случае не размещайте абсолютно все запасы на единственной базе, да еще и в конкретном помещении. В таком случае после случайного налета кучки любителей халявы вы потеряете абсолютно все. Конечно, вряд ли у новичка хватит ресурсов, чтобы построить себе 4-5 домов и правильно распределить по ним ценные предметы, но хотя бы попробуйте сделать что-то подобное. Неплохим решением будет на территории одной базы построить несколько «нычек» и распределить по ним ресурсы и предметы.
Не забывайте про аптечки
Если вы решите, что аптечки вам не нужны и со своим крутым автоматом вы сможете одолеть кого угодно, то Rust очень быстро вас разочарует. Здесь очень просто погибнуть, и иногда вы даже не будете понимать, почему это вообще произошло. В результате игрок, у которого было полно аптечек, просто завалит вас рандомной палкой и заберет тот самый крутой автомат.
Поставьте себе домофон
Если же вы не можете сделать кодовый замок или уже поставили везде обычные двери, то не делайте ключ. Пускай доступ к зданию будет только у вас. Отсутствие ключа гарантировано защитит ваши владения, даже если вы внезапно погибнете.
Не используйте факел
Дело в том, что свет от факела моментально привлечет к вам внимание других игроков. Часть из них будет гриферами, которые быстро прибегут на ваш «сигнал» и просто убьют. На этом ваш многообещающий забег в Rust просто закончится и придется начинать все сначала. Первое время лучше бегайте без факела и пытайтесь ориентироваться на карте с помощью своего зрения.
Вы всегда в опасности
Многие новички ошибочно думают, что после того, как они построят себе укрытие и обзаведутся хоть какой-то экипировкой, можно просто расслабиться и наслаждаться игровым процессом Rust. Этот проект не об этом, вы всегда будете под прицелом у других игроков! Причем если у вас вдруг все слишком хорошо и на это обратят внимание остальные пользователи игровой сессии, то очень скоро вас ждет набег незваных гостей.
Перестрелка – не самая лучшая идея
Некоторые новички в Rust почему-то считают, что это экшен-шутер, в котором прямо-таки необходимо ввязываться в перестрелки и каждую минуту показывать, кто здесь круче. На самом деле проект про выживание, и я вам гарантирую, что ваша беготня с автоматом закончится очень быстро, если вы вдруг решите, что можете держать всю карту в страхе.
Вот такие советы мы решили дать новичкам, которые только надумали залететь в Rust! Делая все эти вещи, вы гарантировано проживете в виртуальном мире игры чуточку дольше и при этом гораздо лучше узнаете все тонкости проекта. Главное, не забывайте всегда быть начеку, здесь нет зоны комфорта.
Заменяем глобальный аллокатор в Rust
Вторая часть про работу с кучей, устанавливаем свой глобальный аллокатор. В принципе, это делается в несколько строк, но наша цель — действовать сознательно и профессионально, с глубоким проникновением в суть явлений, так что легкой жизни не будет (как и обещал).
static и const
В японском зоопарке родился слоненок — казалось бы, при чем тут Лужков? Глобальный аллокатор, static и const?! — Спокойно, действуем по ранее утвержденному плану. Да и все равно изучать.
Рассмотрим такой пример:
static и const:: Адрес
Результат какой-то такой:
Посмотрим в ассемблер, благо чудесный play.rust-lang.org это позволяет:
Ну т.е. вроде как отдельные адреса заведены под все значения. Стоит ли полагаться на то, что адрес const-значения ( L__unnamed_2 ) постоянен? Как водится, внятное описание мы найдем в «старом учебнике»:
More specifically, constants in Rust have no fixed address in memory. This is because they’re effectively inlined to each place that they’re used. References to the same constant are not necessarily guaranteed to refer to the same memory address for this reason.
static и const:: Встраивание (Inlining)
«. they’re effectively inlined» — ой ли?
Любую документацию по Rust надо рассматривать либо как неполную, либо как противоречивую (собственно, Гёдель), а в The Rust Reference авторы сами пишут красными буквами:
Warning: This book is incomplete
Так что будем проверять все, что можно проверить, благо, инструментарий имеется.
Погрузимся в глубины присваивания, напрямую можно присваивать только const:
Посмотрим в ассемблер вот такого кода:
Но постойте, мы же можем и static присвоить, для этого надо реализовать Copy :
Короче, разницы, в плане «встраивания», между static и const на нашем примере не видно (понятно, что с поправкой на то, что Copy is-a-must).
static и const:: Изменяемость (Mutability)
Ни одно из «значений» не может быть изменено в безопасном режиме, по разным причинам:
MUT_STATIC_POINT можно изменить в unsafe:
Попытки изменить STATIC_POINT или CONST_POINT заканчиваются ужасами Segmentation fault:
static и const:: Инициализация
Ну и, наконец, общим для всех этих… ээээ… «переменных» является то, что функции, их инициализирующие, должны быть объявлены с квалификатором const :
static и const:: Деструктор
Как утверждает отличное старое руководство, метод Drop::drop() для static переменных может быть реализован, но он не вызывается.
static и const:: Что использовать?
Прекрасный ответ дает RFC-0246:
Для замены глобального аллокатора осталось освоить немного: тип unit, unit-like структуры, и значения параметров типа по умолчанию.
Тип unit
In the area of mathematical logic and computer science known as type theory, a unit type is a type that allows only one value (and thus can hold no information).
…
In Haskell and Rust, the unit type is called () and its only value is also (), reflecting the 0-tuple interpretation.
…
In Java, the unit type is called Void and its only value is null.
…
Unit type
Итак, пустой кортеж (tuple) () означает одновременно и тип, и литерал (фиксированное значение). Можно писать так:
Unit-like структуры
Unit-like структуры, как понятно из названия, также представляют собой и тип, и литерал:
Для комплекта возьмем еще std::alloc::System (мы потихоньку подбираемся к глобальному аллокатору) и напечатаем их адреса:
Это все, конечно, интересно, но каково же практическое применение? Еще немного теории, и приступим к практике.
Значения параметров типа по умолчанию
Все работает, но в процессе эксплуатации понимаем, что println!() надо бы заменить вызовами некоего нормального логгера, и Server у нас теперь выглядит вот так:
Но сперва надо где-то взять реализацию Logger. Если нет желания создавать экземпляр, можно использовать как «носитель» любую unit-like структуру в области видимости, например, реализуем Logger для std::alloc::System:
Может создаться впечатление, что здесь происходит процесс, известный как «Внедрение зависимости» (Dependency Injection), т.е. код:
Этот момент чрезвычайно важен, для его понимания сделаем второй логгер:
… и заглянем за кулисы:
Замена глобального аллокатора
Замена глобального аллокатора описана здесь, так заменим:
Реализация зависит от платформы, «условная компиляция», видимо, происходит здесь:
Теперь посмотрим, как работает std::alloc::alloc() из предыдущей серии.
std::alloc::alloc()
С #[global_allocator] все понятно, идем в __rdl_alloc():
Аллокатор в RawVec
Далее пойдем только в ветку с alloc(layout):
Чем Rust отличается от «плюсов»: откровение ветерана С++
Rust часто называют преемником C++. Дмитрий Свиридкин рассказал на суровом программистском языке, так ли хорош любимчик пользователей Stack Overflow.
Программист. Разрабатывает на C++ и Rust решения для платформы компьютерного зрения в Arrival. Автор сборника материалов по C++.
Я решил попробовать Rust, потому что устал отлавливать на код-ревью (и не только) одни и те же ошибки в «плюсах». Обязательно кто-нибудь объявит статик-лямбду и захватит в неё по ссылке нестатический временный объект. А когда код с такими ошибками коммитят, он проходит тесты, предполагающие однократный запуск. Программа попадает в продакшен, где запускается пару раз и падает. На поиск и отладку багов уходит много сил и времени.
В Rust нет бардака с библиотеками
У С++ всегда было две проблемы: недостаточная квалификация разработчиков и отсутствие нормальных пакетных менеджеров.
Раньше приходилось гуглить, копировать и компилировать исходники библиотек — та ещё головная боль. Бывало, найдёшь исходники, а компилятор не подходит, потому что он слишком старый, хедеры протухшие или версии зависимостей не совпадают. Тогда вместо готового решения придумывали своё — и это своё всегда заканчивалось кучей багов.
Например, я видел реализации std::optional, которые не вызывают деструктор, даже если тип нетривиально деструктурируемый. Тогда как стандартная реализация — это куча boilerplate-кода, который даже командой из трёх-четырёх человек невозможно отладить.
Получается полный бардак. Часть кода покрывают тестами, она кое-как работает, а когда начинаешь детально тестировать — тут дедлок, там use-after-free и так далее. В Rust эти заботы можно частично переложить на плечи компилятора, но с ним иногда приходится бороться: богатая система типов требует более педантичной работы.
Чтобы писать на Rust, мне не пришлось менять IDE. Просто подключил к VS Code code-assistant rust-analyzer (это что-то вроде майкрософтовского IntelliSense). На прошлой работе писали в CLion от JetBrains. У неё есть неплохой плагин для Rust, но при рефакторинге он может наделать делов и оказать медвежью услугу. Так что IDE от JetBrains научили меня не доверять авторефакторингу — обязательно что-нибудь да сломается. Поэтому стараюсь аккуратно рефакторить сам.
Система типов в Rust защищает от ошибок
Бизнес-логика — именно то, что нужно писать на Rust, потому что с ним тяжело ошибиться. Ещё на прошлой работе мы запилили плагин — в качестве proof of concept того, что на Rust вообще можно создавать плагины к большому SDK. Логика была примитивная: принять список слов и проверить, совпадает ли с ним input.
Почему такой простой плагин? Потому что больше никто в команде не знал Rust. Язык молодой, и пока на нём мало кто пишет. Создавать проекты, которые может поддерживать только один разработчик, невыгодно. Проще найти «плюсовиков», поэтому C++ никуда не исчезнет.
На новой работе я перевожу часть проекта с «плюсов» на Rust. Язык подкупил меня мощной системой типов, которая позволяет выразить зависимости между временами жизни объектов. В языках с ещё более мощными системами типов, например с зависимыми типами, можно проверять статически рантаймовые ограничения. Например, запретить функции принимать пустые строки — компилятор проверит.
Однако у таких мощных языков есть общая проблема: вы замучаетесь доказывать компилятору, что код работает правильно и ничего в нём не нужно исправлять. К счастью, Rust не совсем такой, это золотая середина: с одной стороны, его система типов достаточно строгая, чтобы защитить вас от распространённых ошибок. С другой — не настолько строгая, чтобы приходилось мучиться с ней лишнего.
Программы на Rust без стороннего кода сравнимы по скорости с «плюсовыми»
На прошлой работе я переписывал большой графовый алгоритм — без unsafe-кода, с контейнерами из стандартной библиотеки.
По производительности программа была всего на 10% медленнее «плюсовой». При этом обошлись без стороннего кода. Считаю, что результат хороший. Под C++ пришлось три месяца искать hashmap и перебирать варианты: в одной выравнивание как-то хитро сконфигурировано и приводит к segfault, в другом exception вылетает, если хеш плохой, третий вообще уже четыре года не поддерживается.
Что же касается бенчмарков, то всегда можно подобрать тест, где выиграет нужный язык — хоть С++, хоть Rust. Достаточно знать тонкости работы с памятью в конкретном языке. Я, например, могу написать пример кода на Rust без лишних аллокаций, а в «плюсах» у аналогичной программы они будут, потому что организовать там safe по-другому нельзя. В общем, обсуждать производительность нужно на конкретном примере.
Code-assistant rust-analyzer отлично работает с шаблонами
В последнее время я оборачиваю небезопасные библиотеки языка С, чтобы подцепиться к каноническому Rust API. Если бы сразу начал писать на «плюсах», уже давно бы закончил и общался с железом, к которому эта библиотека поставляется. А так как пишу на Rust, то пришлось целую неделю аккуратно оборачивать код в канонические Rust-структуры. Столкнулся с тонкостями системы типов: вариантностью ссылок, контравариантностью типов. Если не обращать на них внимания, то safe-обёртка над C API будет некорректной.
Оборачивать низкоуровневый unsafe-код в safe на Rust довольно долго, но оно того стоит. «Плюсовой» IntelliSense вряд ли сравнится с мощным rust-analyzer и справится далеко не со всем кодом, особенно с шаблонами.
Возможно, с появлением стандарта С++20 появятся хинты и IntelliSense научится подсказывать внутри шаблонного кода, если в параметрах указать концепт. Думаю, раньше всех эту фичу внедрит в свои IDE JetBrains — если уже не начала втихаря над ней работать. Шаблоны без концептов в «плюсах» всегда работали плохо: стоит поставить неподходящий аргумент — и компилятор выдаёт огромные сообщения об ошибках. Пока у анализаторов Rust гораздо больше возможностей, да и писать шаблонный однотипный код на нём получается гораздо быстрее.
У Rust настоящая zero-cost abstraction
Помимо Rust, я присматривался и к другим языкам. Три года назад, когда впервые сменил работу, думал погрузиться в светлый мир JVM и написать что-нибудь на Kotlin. Но языки вроде Scala, Java и Kotlin можно применять далеко не везде. Виртуальные машины создают дополнительную нагрузку и для встраиваемого ПО в микрокомпьютерах не подходят. В таких системах пишут на чистом С, С++ или совсем страшных штуках вроде MISRA C.
У Rust, скомпилированного в native, нет дополнительного рантайма. RAII, деструкторы, конструкторы как в «плюсах». Только у Rust линейные типы и zero-cost с ними настоящий, а у C++ — нетривиальный деструктор у типа, и хоть убейтесь, но не получится передать его значение через регистры.
Ещё есть Zig — он очень похож на Rust. Там, например, тоже есть проверка lifetime, но организована она иначе, и то, как это сделано в Rust, мне нравится больше. Других языков с проверкой lifetime я не знаю, а в языках со сборщиками мусора она не нужна: если есть ссылка на объект, значит, он точно живой.
В Go механизм похожий, но там есть сборщик мусора. Мне предлагали перейти на него четыре года назад. Я попробовал, и синтаксис меня рассмешил. Стоит автоформатеру неправильно перенести строки, и программа не скомпилируется. А всё из-за неявной расстановки точек с запятой.
С похожей проблемой я сталкивался, когда мы в первый раз подключали сторонний форматер для «плюсов» — кажется, это был Uncrustify. Он убрал лишние фигурные скобки, и размер критических секций у меня резко вырос. Да уж, отличный форматер — поменял поведение программы. Мог бы просто весь код снести.
В Rust более лаконичный синтаксис, но к нему нужно привыкнуть
Вообще, синтаксис Rust меня вначале сильно раздражал, но я уже почти смирился с ним.
Раздражает символ ; в конце expression, который меняет возвращаемый тип на аналог сишного void. Поставил точку с запятой — программа перестаёт компилироваться. А компилятор молотит type-чекером, который занимает целое ядро, чтобы rust-analyzer и IDE написали красным: «Смотри, у тебя тут типы не сошлись».
Хорошо хоть в экосистеме Rust пофиксили много ошибок и в поставке уже есть официальный форматер, который всё делает правильно. Конечно, тоже есть проблемы. Например, если вы хотите сделать что-то серьёзное с пакетными менеджерами, например сложить собранные артефакты в каталог, то придётся вручную писать поверх скрипты, например на Bash. Штатными средствами это сделать либо нельзя, либо они unstable.
В целом я свыкся с упоротым синтаксисом и краткими ключевыми словами, но всё равно считаю, что они должны состоять хотя бы из трёх символов. Я люблю называть свои переменные fn, а мне его предлагают в качестве ключевого слова. С другой стороны, минималистичный синтаксис — это хорошо.
Лямбды можно писать кратко и без ключевого слова return — это экономит кучу времени. Зато когда после этого переключаешься на С++, то всё время забываешь писать return и, указав тип возврата, получаешь функции с неопределённым поведением. В С++ синтаксис лямбд вообще напоминает синтаксис обычных функций, только trailing return type сделали — ну, и на том спасибо, что уж там. А скобки и return нужно писать обязательно, иначе будете ждать от функции int, а она ничего не вернёт.
При этом Rust не панацея
Тех, кто только планирует погрузиться в Rust, предупреждаю: это не панацея от всех болячек C++. Он защищает вас от гонки данных через проверку borrow checker, но пропускает дедлоки. Защищает от use-after-free, но только в safe-подмножестве. Если же работаете с unsafe — у вас, по сути, будет тот же С++, только с более продвинутой стандартной библиотекой.
Хотя и здесь не всё так однозначно. Многие важные фичи, например для разработки драйверов или встроенного ПО, остаются нестабильными, а значит, писать на Rust серьёзные проекты пока рискованно. По этой причине от Rust часто отказываются в пользу C++, где всё давно stable и unsafe.
обложка: Polina Vari для Skillbox Media