Каждый раз, когда вы пишете .await, происходит не магия, а вполне конкретный механизм: Future, Waker и опрос состояния. Чтобы увидеть это своими глазами, я написал собственный async-рантайм на Rust с нуля - с executor, reactor на epoll и рабочим TCP-эхо-сервером. По пути разобрался, как именно tokio будит ваши задачи, и нашёл баг, который тихо висел у меня в проде. Внутри - весь код целиком и объяснение без отсылок к чёрным ящикам.

Миллион асинхронных задач на Rust спокойно живёт в нескольких сотнях мегабайт. Сто тысяч корутин на Python нередко упираются в память раньше. Дело не в том, что “Rust быстрый, а Python медленный” - дело в том, ГДЕ физически лежит состояние приостановленной задачи.

Разбираю, во что превращается ваш async fn после компиляции: стейт-машина на стеке против объекта в куче. Сравниваю модели Rust (Tokio), Python (asyncio), C# и JavaScript - кто аллоцирует на каждый await, а кто нет, и почему это видно на счётчике RAM при 100k задач.

Внутри: что генерирует компилятор, куда уезжает состояние между await, stackful против stackless, и что с этим делать сегодня.

Я срьрал 100+ вопросов с собеседований по Rust с краткими разборами: владение, типажи, конкурентность, async, unsafe, производительность и др. Отдельный продвинутый блок A1–A21 для staff-уровня. Цель - показать, где обычно спотыкаются даже опытные, и помочь подготовиться к следующему собеседованию. Надеюсь будет реально полезно!

io_uring продавали как убийцу epoll. На деле на HTTP keep-alive разница 0-15%, иногда не в его пользу. Но на NVMe с queue depth 128 - в 3 раза быстрее. Честный разбор с бенчмарками, реальными граблями (SQPOLL, cancel race, partial recv) и почему Google отключил io_uring в ChromeOS.

Полгода я давал LLM писать unsafe Rust в боевых проектах и разбирал каждый блок под miri и санитайзерами. Категории ошибок, которые модели делают стабильно: aliasing, провенанс, layout в alloc/dealloc, забытый ManuallyDrop, гонки в FFI-колбэках, ручные Send/Sync, uninit-память, Pin. Каждая категория идёт с минимальным примером и фиксом.

Полгода использовал Claude, GPT и Cursor как полноценного второго разработчика на Rust в проде. Собрал семь категорий ошибок, которые модели стабильно делают и которые проходят cargo build, cargo test, иногда cargo clippy и при этом являются UB или скрытыми архитектурными ловушками. Lifetime laundering, std::sync::Mutex через .await, Drop у транзакций, unaligned read, async cancellation, orphan rule и массивы на стеке. Разбираю, почему именно Rust ломает LLM и что с этим делать.

async fn в Rust — это не магия и не зелёный поток, а обычный enum, который компилятор генерирует за тебя. Разбираем, почему Future это машина состояний, зачем нужен Pin, как работает Waker и executor, и как одна .await-точка может незаметно заставить твой сервис есть память гигабайтами.

Rust давно перестал быть языком энтузиастов. На нём собраны куски ядра Linux, движки баз данных и аналитики (TiKV, Materialize, Polars), бэкенды Cloudflare и Discord. Под Rust пишут прошивки для ESP32 и STM32, фронтенд через WebAssembly, инференс LLM.

Microsoft переписывает части Windows, AWS строит на Rust Firecracker и Bottlerocket, Google пускает его в Android и в дерево ядра. По зарплатам Rust пятый год держится в верхнем дециле Stack Overflow Survey, и семь лет подряд - самый любимый язык разработчиков.

Если взять случайный крейт с crates.io и поставить его под Miri, шанс увидеть undefined behavior где-то в зависимостях стремится к единице. Разбираемся, почему: pointer provenance, Stacked Borrows, Tree Borrows и почему noalias в LLVM выключали три раза.

Как Rust обманывает процессор. Часть 2: niche сквозь крейты, dropck, Pin и провенанс указателей

В первой части мы обсуждали niche-оптимизацию, drop flags, MIR, Stacked Borrows и async-стейт-машины. В комментариях справедливо заметили (спасибо, Mingun): про niche рассказано в простой форме - Option<&T> и NonZeroU8.

А что происходит, когда enum живёт в одном крейте, оборачивается в newtype в другом, и оба варианта внешнего enum хранят один и тот же внутренний? У такого внешнего типа всего четыре состояния, байта должно хватить. Хватит ли? Зависит от того, как rustc считает layout. Об этом и поговорим.

Во второй части идём глубже: niche сквозь границы крейтов, variance, Pin и самоссылающиеся футуры, dropck с #[may_dangle], Tree Borrows вместо Stacked Borrows и strict provenance. Без этого половина unsafe-кода в экосистеме держится на честном слове.

Большинство статей про Rust заканчиваются на borrow checker и lifetimes, как будто внутри компилятора живёт только проверяльщик заимствований и злой шрифтовый дизайнер для сообщений об ошибках. На деле там целый зоопарк механизмов, о которых редко пишут даже на конференциях. Я собрал несколько по настоящему любопытных вещей, которые меняют представление о том, как устроен язык изнутри, и подкрепил каждый сюжет кодом, который можно скопировать и проверить самому.

Начнём с того, чего никто не ждёт. Знакомая всем конструкция Option ссылки занимает ровно столько же байт, сколько и обычная ссылка. Это кажется магией: ведь у Option должен быть тег, отличающий Some от None. Никакого тега нет. Компилятор знает, что ссылка в Rust никогда не может быть нулевой, и использует нулевой адрес как представление варианта None. Этот трюк называется niche optimization, и он работает гораздо шире, чем принято думать. Проверим руками.