Привет! Меня зовут Иван, и я автор проекта «Код на салфетке» — небольшой команды, в которой мы совмещаем написание обучающих статей, коммерческую разработку и open source.
Сегодня расскажу об одном из наших инструментов, который родился из боли всей команды: как мгновенно узнавать о проблемах в CI/CD, не заглядывая в почту и не обновляя вкладку репозитория.
Когда я начал работу над Architect of Ruin в декабре 2023 года, то решил делать её в игровом движке Bevy. Мой выбор был мотивирован собственным интересом к Rust — языку, от работы с которым я получаю много удовольствия. Ещё больше меня привлекла в этом движке модель ECS, с которой мне тоже нравится работать, а также сообщество Bevy, которое мне очень симпатично.
Поэтому стало неожиданностью то, что в январе 2025 года мы выполнили миграцию нашей игры с Rust и Bevy. Я потратил примерно шесть недель, чтобы полностью переписать игру на C#, и последние три месяца мы работаем в Unity.
Смена движка — частый убийца проектов. При этом может резко снижаться продуктивность, неизбежно возникают регрессии, а каждый шаг вперёд как будто приводит к трём шагам назад. Не говоря уже о том, что опыт работы с одним языком и движком нельзя полностью перенести на новый язык и движок.
Но мы решились на это, и в посте я объясню, почему.
Статья-практикум показывает, как устроены HTTP/2, HTTP/3 (QUIC) и gRPC на самом низком уровне. Вместо толстых библиотек мы пишем минимальный учебный фреймворк «Mini-Transport» на Rust (~600 строк): реализуем кодек HTTP/2-фреймов, упрощённый gRPC-протокол и базовую обёртку над QUIC. В результате получаем рабочий echo-клиент и сервер, которые пересылают «hello ↔ world» через собственноручно собранные фреймы. Разбор сопровождается поясняющими схемами, ссылками на RFC, вариантами дальнейшего развития (HPACK, flow-control, TLS/ALPN) и готовым репозиторием для самостоятельных экспериментов. Материал рассчитан на разработчиков, желающих понять «как всё крутится под капотом» и прокачать навыки низкоуровневой сетевой работы в Rust.
Привет, Хабр!
Я прочитал статью Migrating away from Rust и хочу поделиться с вами своими мыслями, заодно переведя оригинал. Я буду вести повествование от своего лица, поскольку это скорее реакция и размышления, а не традиционный перевод.
Для меня тема весьма актуальна, так как я сам нахожусь в этом странном лагере разработки игр на нишевых движках. Я использую не Rust+Bevy, а Go+Ebitengine, но многие плюсы и минусы этих комбинаций интересно рассматривать как дополняющие друг друга.
Когда-нибудь, я обязательно напишу статью о своём опыте серьёзной разработки игр на Go, но пока я слишком сильно завертелся в рабочем процессе, чтобы успеть доделать демку своей игры до Steam Next Fest. Будет ли эта статья положительная, или это будет миграция на Godot? Кто знает!
Ну а пока, погнали разбирать статью.
Хочу сразу пояснить, что я лично пишу на Go уже около 10 лет и уходить от него не планирую. Но тем не менее мне интересно мнение других разработчиков, которые работают или работали с Go на больших проектах. Во многом я согласен с недостатками Go, описанными ниже, так как сам сталкиваюсь с этими проблемами и на не самых больших проектах. Вот мой перевод статьи.
Привет, Хабр!
Сегодня рассмотрим, как один единственный #[derive(Ord)], казалось бы безобидный, может сломать сортировку, нарушить контракт PartialEq, и вызвать странные баги в BTreeMap, .sort(), или даже в логике dedup.
Привет, Хабр!
На дворе 2025, и у каждого языка свой подход к сборке, зависимостям и публикации. В Rust за это отвечает Cargo — инструмент, который берёт на себя всё: от менеджмента зависимостей до тестов, бенчмарков и выкладки на crates.io.
И вот это мы и рассмотрим в статье: как устроен Cargo изнутри, зачем нужен Cargo.toml, как подключать зависимости, куда падают артефакты сборки, что делает cargo check, как запускать и бенчмаркать, и как наконец создать свой крейт на crates.io.
Зима 2024, в процессе думскроллинга фида реддита я в очередной раз натыкаюсь на пост про hand‑wired эргономичную клавиатуру. В целом я не испытывал особого дискомфорта при использовании обычных клавиатур, но сама концепция привлекала — возможно, своей относительной экзотичностью на фоне «традиционных» клавиатур. Готовые клавиатуры такого формата есть в продаже, но эта опция была быстро отброшена — банально дорого — дешевых вариантов на тот момент особо не было. Прикинув, что до отпуска осталось не так и долго я загорелся идеей — а почему бы, собственно, не попробовать сделать подобную клавиатуру в свободное время?
FFmpeg — это мощный инструмент для работы с мультимедиа, который используют для кодирования, декодирования, перекодирования и применения фильтров к видео и аудио. Но если вы работаете с Rust, интеграция с C API FFmpeg может стать настоящей головной болью: управление памятью, проблемы безопасности и крутая кривая обучения. Особенно сложно реализовать пользовательские фильтры — для этого обычно нужно писать код на C и разбираться во внутренностях FFmpeg. А что, если я скажу, что с Rust и библиотекой ez-ffmpeg вы можете забыть про эти трудности и писать фильтры прямо на любимом языке?
В этой статье мы разберём, как использовать Rust и ez-ffmpeg для создания собственных видеофильтров. Мы начнём с основ, дойдём до продвинутых решений и покажем, как это может пригодиться именно вам. Готовы упростить свою жизнь? Тогда поехали!
FFmpeg — это мощный инструмент для работы с мультимедиа, который широко используется для редактирования видео, конвертации форматов и других задач. Однако использование командной строки FFmpeg (CLI) напрямую может быть связано с определёнными сложностями:
Обработка аудио и видео может показаться сложной задачей, но в разработке нам рано или поздно приходится сталкиваться с такими задачами, как конвертация форматов видео, обрезка, добавление водяных знаков или извлечение аудио.
FFmpeg — это признанный стандарт в индустрии, который умеет почти всё. Его используют популярные программы, такие как VLC, YouTube и OBS. Однако у FFmpeg есть свои подводные камни, которые могут доставить разработчикам головную боль:
Привет, Хаброжители!
На примерах попробую показать, почему enum в Rust это несколько больше, чем обычно принято считать. Рассмотрю расширенное использование enum в типовых ситуациях. Сразу забегая вперед скажу, что в рамках статьи я не затрагиваю паттерны и мэтчинг.
Первое, что приходит в голову, когда речь заходит об enum, — это идея: «А давайте заменим все константы на enum». :) Желание логичное, давайте на него посмотрим...
Enum — одна из самых популярных фич Rust. Тип enum может иметь одно из значений в заданном множестве вариантов.
/// Foo имеет значение или 32-битного integer, или символа.enum Foo { Int(u32), Char(char),}
Значениями типа Foo могут быть или integer (например, вариант Foo::Int(3) с полезной нагрузкой 3), или символы (например, вариант Foo::Char('A') с полезной нагрузкой 'A'). struct можно считать AND-комбинациями их полей, а enum — OR-комбинациями их вариантов.
Этот пост посвящён удивительной оптимизации, выполняемой компилятором Rust с представлением в памяти значений enum, чтобы они занимали меньше места в памяти (спойлер: это не нишевая оптимизация). В общем случае, уменьшение размера значений может привести к ускорению программ, потому что значения передаются в регистрах CPU и в одну линию кэша CPU умещается больше значений.
Команда Rust рада сообщить о новой версии языка — 1.86.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.
Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.86.0 вам достаточно выполнить команду:
$ rustup update stableЕсли у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.
Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках.
Как быстро, без боли и страданий организовать хранение структурированных данных в бинарном формате. А затем и их передачу при необходимости. А потом, немного подумав, ещё их обнаружение в «замусоренном» потоке.
Идея создания этого пет-проекта возникла из желания написать собственного ИИ-агента. Я сформулировал для себя минимальные технические требования: агент должен иметь несколько состояний, уметь запускать тулзы и использовать RAG для поиска ответов на вопросы.
В итоге возникла идея написать персонального телеграм-ИИ-бота, который умеет запоминать нужную мне информацию, и когда мне надо — я могу его спросить, что он запомнил. Что-то вроде блокнота, только это будет ИИ-блокнот, который умеет отвечать на вопросы. В дополнение я решил добавить в него функцию, чтобы он мог запускать команды на сервере — причём команды, описанные человеческим языком, он будет переводить в команды для терминала.
Изначально я думал использовать LangChain. Очень хороший инструмент — позволяет подключать векторные базы данных, использовать различные LLM как для инференса, так и для эмбеддинга, а также описывать логику работы агента через граф состояний. Можно вызывать уже готовые тулзы. В целом, на первый взгляд всё выглядит удобно и просто, особенно когда смотришь типовые и несложные примеры.
Но, покопавшись немного глубже, мне показалось, что затраты на изучение этого фреймворка не оправдывают себя. Проще напрямую вызывать LLM, эмбеддинги и Qdrant через REST API. А логику работы агента описать в коде через enum, описывающий состояния, и делать match по этим состояниям.
К тому же LangChain изначально написан на Python. Я хотел бы писать на Rust, а использовать Rust-версию LangChain — сомнительное удовольствие, которое обычно упирается в самый неподходящий момент: что-то ещё не было переписано на Rust.
Привет, Хабр!
const fn в Rust давно перестал быть просто инструментом для сложения чисел на этапе компиляции. Сегодня это мощный инструмент, который умеет циклы, условия, матчинг, парсинг и даже кусочки бизнес-логики — и всё это ещё до запуска программы.
В этом посте будет разобрано, как написать приложение на Rust с применением самого минимального API, возможности которого искусственно ограничены (например, не применяется динамическое выделение памяти). Предполагается, что читатель немного знаком с языком Rust.