Rust *

Я наблюдаю за тем, как люди снова и снова совершают одни и те же ошибки при изучении Rust. Ниже представлены мои мысли (в порядке важности) о том, как можно упростить себе процесс обучения. Моя цель — помочь вам сэкономить время и избежать разочарования.

Расслабьтесь

Перестаньте сопротивляться. Это самый важный урок.

Примите то, что для изучения Rust требуется освоение совершенно иной и непривычной вам ментальной модели. В языке есть куча новых концепций, например, сроки жизни, владение и система трейтов. В некоторых случаях для вас будут новыми дженерики, сопоставление с образцом или макросы.

Темп обучения не особо зависит от вашего ума и предыдущего опыта программирования. Главнее всего ваше отношение к языку.

Я видел разработчиков-джунов, прекрасно справлявшихся с Rust без предварительного обучения, и сениоров, которые боролись с ним неделями/месяцами или полностью капитулировали. Забудьте о своей гордыне.

С недавнего времени в QEMU появилась экспериментальная возможность создания моделей устройств на языке Rust, вместо традиционного C. Меня эта тема очень заинтересовала, и я не смог пройти мимо и не попробовать не создать модель устройства PCI на этом языке. За основу взял реализацию EDU на C.

Делюсь, через что мне пришлось пройти, и что из этого вышло. Эта часть посвящена разбору интеграции Rust в QEMU.

Всем привет! Моя первая статья получилась... слабой. Постарался сделать работу над ошибками и заодно ответить на вопросы, возникшие в комментариях. Прошу дать мне второй шанс!

Первый блин комом)

Всем привет! Пишу свою первую статью — не судите строго:‑)

Сегодня хочу рассказать вам о своём проекте, а точнее показать его в деле. Надеюсь, вам будет интересно!

Всем привет. Я студент 2 курса магистратуры Университета ИТМО факультета «Школа разработки видеоигр». В своей выпускной работе «Анализ и разработка алгоритма Shadow Mapping направленных источников света для систем с несколькими GPU» я перенёс вычисление Cascaded Shadow Maps на вторую видеокарту и получил 40% прироста к производительности.

Всё началось невинно. Шёл 2009 год, и я просто хотел портировать Earcut на Flash - для своей мини-игры. Тогда это сработало, но с годами стало понятно: простые решения перестают работать, как только хочешь выжать из них максимум.

Мэтт Годболт, знаменитый разработчик Compiler Explorer — потрясающий человек, вам стоит найти в вебе и изучить весь созданный им контент. Именно этим и занимался, просматривая Correct by Construction: APIs That Are Easy to Use and Hard to Misuse. Я уже больше двадцати лет работаю с C/C++, поэтому эта тема была мне близка.

Когда я смотрел его доклад, ко мне постоянно приходила мысль: «Да! И именно поэтому в Rust это делается так». После просмотра видео я подумал, что этот доклад — отличный способ понять, как Rust помогает разработчикам не только в безопасности по памяти, и в своей статье я расскажу об этом.

Но прежде нам следует поговорить о поднятых Мэттом проблемах и о том, как он предлагает решать их в C++. Сделайте себе одолжение и посмотрите доклад целиком, а я разберу один из его пунктов.

Во вселенной распределённых систем существует древний цифровой организм — Wormhole, или, как его называют в инженерных кругах, Хранитель туннелей.

Он не живёт в серверах, не привязан к IP-адресам и не сохраняет ничего в облаке. Его среда — шум пустоты между узлами. Он рождается каждый раз, когда два устройства обмениваются публичными ключами. Его тело состоит из энергии шифрования, а глаза — это криптографические nonce, всегда уникальные, всегда непредсказуемые.

Он не говорит. Он доставляет.

Каждое сообщение, проходя через его туннель, исчезает для всего мира — кроме одного получателя. Он не знает, что вы говорите, но знает, что это должно остаться между вами.

Когда вы запускаете Wormhole Messenger — вы не просто открываете чат. Вы пробуждаете существо, которое живёт между пингами, между кадрами WebSocket. Маскот — это визуальный облик этого криптографического духа, появляющегося каждый раз, когда вы выбираете приватность.

Здравствуйте, уважаемые читатели!

В этой статье я хотел бы поделиться необычным и вдохновляющим проектом — реализацией арканоида в текстовом VGA-режиме, написанного полностью на Rust, без использования стандартной библиотеки и даже без аллокации памяти (#![no_std] + no_alloc).

Проект работает напрямую с VGA-памятью и PS/2 клавиатурой через порт 0x60, создавая абсолютно нативную игру в стиле 80-х, но с современным вниманием к качеству кода. И всё это — с участием милого талисмана Platinum-tan.

Привет! Меня зовут Иван, и я автор проекта «Код на салфетке» — небольшой команды, в которой мы совмещаем написание обучающих статей, коммерческую разработку и 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) напрямую может быть связано с определёнными сложностями: