KO | EN

GitLite

Minimalist Open Source Repository Search Engine

gitlite — search

#dsh #dsh-plugin #deepseek-harness #typescript #ai-agent #codex #developer-tools #claude-code #windows #mcp #python #desktop-app

rustinterviewquiestions

★ 90 Open GitHub ↗

Rust вопорсы с собеседований

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Rust Interview Deep Dive

Системная подготовка к собеседованиям по Rust на позиции middle, senior и staff. Сто реальных вопросов с интервью в продуктовых и инфраструктурных компаниях, подробные разборы с кодом и задачи, которые встречаются в продакшене. Фокус на механике языка, на которой держатся настоящие сервисы, а не на угадывании вывода программы.

В разборах есть lock-free структуры, self-referential типы в async, FFI с тензорными библиотеками, корректный Send на гардах через await, memory ordering под loom, soundness кастомных коллекций. База тоже на месте: владение, заимствование, лайфтаймы, базовые трейты. Заходить можно и с нуля, и с уровня staff.

**Зачем учить Rust в эру вайбкодинга.** Модели пишут код. Но они не несут ответственности за то, что собрал компилятор, и не объяснят, почему async-стейтмашина не Send. Вайбкодинг хорошо работает на склейке, на конфигурации, на фронтенде. Он ломается там, где нужно понять, почему в продакшне потекла память, откуда data race под нагрузкой, как правильно обернуть C-библиотеку без UB. Rust — язык с явным контрактом: компилятор не пропустит то, чего ты не понимаешь. Это делает его одновременно сложнее для вайб-разработки и ценнее: там, где LLM выдаёт внешне правильный unsafe-код с невидимым UB, понимание языка — единственный фильтр. Кроме того, Rust активно заходит в AI-инфраструктуру: Candle, Burn, tch-rs, Polars, qdrant, Milvus-компоненты — всё это Rust. Понимать язык на уровне senior/staff в этом стеке становится конкурентным преимуществом, которое модель не закроет.

Живой контент на русском с уроками и разборами кода — канал [t.me/rust\_code](https://t.me/rust_code). AI, ML и вайбкодинг — [t.me/machinelearning\_interview](https://t.me/+K4iDnNQvdbo5OGQy).

## Содержание

1. [Как работать с репозиторием](#как-работать-с-репозиторием)
2. [Структура репозитория](#структура-репозитория)
3. [Уровни сложности](#уровни-сложности)
4. [Связанные файлы](#связанные-файлы)
5. [Ответы и разборы 100 вопросов](#ответы-и-разборы-100-вопросов)
 - [Владение, заимствование, лайфтаймы](#владение-заимствование-лайфтаймы)
 - [Типы, трейты, обобщения](#типы-трейты-обобщения)
 - [Конкурентность и параллелизм](#конкурентность-и-параллелизм)
 - [Async и runtime](#async-и-runtime)
 - [Unsafe, FFI, низкий уровень](#unsafe-ffi-низкий-уровень)
 - [Производительность](#производительность)
 - [Макросы и метапрограммирование](#макросы-и-метапрограммирование)
 - [Архитектура и дизайн API](#архитектура-и-дизайн-api)
6. [Продвинутые вопросы уровня staff и expert](#продвинутые-вопросы-уровня-staff-и-expert)
7. [Сколько времени занимает подготовка](#сколько-времени-занимает-подготовка)
8. [Полезные ресурсы](#-полезные-ресурсы)
9. [Полезные ссылки](#полезные-ссылки)
10. [Что почитать и попробовать руками](#что-почитать-и-попробовать-руками)
11. [Контрибьютинг](#контрибьютинг)
12. [Лицензия](#лицензия)

## Как работать с репозиторием

Сначала читайте вопрос или условие задачи и пробуйте ответить или решить самостоятельно. Не подсматривайте в `src/lib.rs` и в раздел с ответами, пока не получите рабочую версию хотя бы на бумаге. Только потом сравнивайте свой подход с разбором. Часто наивное решение даже компилируется, но содержит UB или проседает под нагрузкой, и весь смысл в том, чтобы увидеть это самому до того, как прочесть ответ.

Тесты запускайте через `cargo test -p <task-name>`. Где есть бенчмарки, прогоняйте `cargo bench`. Для задач с unsafe обязательно `cargo +nightly miri test`. Для проверки на гонки на сложных async путях полезен `loom`. Clippy и rustfmt держите включёнными в редакторе и в CI.

Если готовитесь к конкретному собеседованию, идите не подряд, а по темам, которые наиболее вероятны на этой позиции. Содержание сверху построено так, чтобы было удобно прыгнуть в нужный раздел.

## Структура репозитория

```
rust-interview-deepdive/
├── README.md # этот файл с вопросами и ответами
├── QA.md # тот же материал отдельным файлом
├── ANSWERS.md # тематические разборы с практическим уклоном
├── POST.md # черновики и заметки
├── CONTRIBUTING.md
├── LICENSE
├── Cargo.toml # workspace
├── .github/workflows/ci.yml # cargo test + clippy + fmt + miri
├── tasks/
│ ├── 01-ownership-move/
│ │ ├── README.md # условие, разбор, подводные камни
│ │ ├── src/lib.rs # реализация
│ │ ├── tests/it.rs # интеграционные тесты
│ │ └── benches/bench.rs # где уместно
│ └── ... до 40/
└── theory/
 ├── memory-model.md
 ├── send-sync.md
 ├── pin-unpin.md
 ├── async-runtime.md
 └── unsafe-invariants.md
```

Каталог `tasks/` это практические задачи с тестами и иногда бенчмарками. Каталог `theory/` это длинные тексты по фундаментальным темам, на которые ссылаются разборы задач.

## Уровни сложности

Middle. Задачи 1 10. Типовые вопросы про владение, заимствование, базовые трейты, базовый async, простое использование Mutex и каналов. Если эти задачи решаются без подглядывания, можно идти дальше.

Senior. Задачи 11 30. Конкурентность, async на чуть более глубоком уровне, unsafe в прикладных дозах, производительность, тонкости трейтов и дженериков. Здесь начинается то, что отделяет уверенного middle от senior.

Staff. Задачи 31 40. Дизайн API, тёмные углы компилятора, макросы и метапрограммирование, FFI, soundness кастомных абстракций, работа с памятью на уровне модели. Эти задачи редко решаются с первого раза, и это нормально.

## Связанные файлы

[`QA.md`](./QA.md) дублирует раздел с ответами и разборами ниже отдельным файлом. Удобно открывать прямо с GitHub без необходимости листать README.

[`ANSWERS.md`](./ANSWERS.md) содержит тематические разборы по восьми разделам. Здесь меньше формата вопрос ответ и больше связного текста с упором на практику. Подходит для того, чтобы освежить тему целиком.

[`POST.md`](./POST.md) черновики и заметки, которые ещё не превратились в полноценные разборы.

Каталог [`tasks/`](./tasks) содержит практические задачи с реализациями и тестами. Идти в задачи имеет смысл после того, как теоретические разделы перестали вызывать вопросы.

## Ответы и разборы 100 вопросов

Ниже идут все сто вопросов с собеседований по Rust, на каждый дан развёрнутый ответ с пояснением механики, рабочий пример кода и короткий комментарий, на что в этом примере стоит смотреть. Документ рассчитан на тех, кто уже пишет на Rust и хочет проверить понимание перед собеседованием или просто разложить материал по полкам. Без воды и пересказа учебника, с упором на то, что реально спрашивают и что реально встречается в коде. Восемь разделов идут в логичном порядке от базы к деталям.

### Владение, заимствование, лайфтаймы

#### 1. Что такое владение в Rust и какие у него три правила

Владение - статическая модель управления ресурсами. Компилятор отслеживает, какой биндинг отвечает за освобождение значения, и в точке выхода владельца из области видимости вставляет вызов деструктора. Никакого рантайма, никакого подсчёта ссылок, никакого GC.

Три правила. У каждого значения есть ровно один владелец. В один момент времени владелец только один, передача владения называется move. Когда владелец выходит из скобок, значение дропается.

Move в Rust - побайтовое копирование стекового представления плюс инвалидация исходного биндинга на этапе компиляции. Для `String` это копирование трёх машинных слов (указатель, длина, ёмкость), а не аллокация. Поэтому move дешёвый и не вызывает Clone.

```rust
fn take(s: String) { println!("{s}"); }

fn main() {
 let a = String::from("hi");
 take(a);
 // println!("{a}"); // E0382: borrow of moved value
}
```

Часто путают: move и глубокое копирование. Move не копирует кучу. Глубокое копирование делает `Clone`. Для `Copy`-типов (примитивы, `&T`, кортежи из Copy) семантика побитовая и исходный биндинг остаётся валидным, потому что `Copy` и `Drop` взаимоисключающие.

Чек для ревью: если функция принимает `String` по значению, она забирает владение. Если потом нужно вернуть строку вызывающему, либо возвращайте её из функции, либо принимайте `&str` или `&mut String`.

#### 2. Чем move отличается от copy и какие типы реализуют Copy

Move и Copy на уровне ассемблера делают одно: `memcpy` стекового представления. Разница в том, что компилятор делает с исходным биндингом. После move исходник инвалидирован и обращение даёт E0382. После copy исходник остаётся валидным.

Copy реализуют типы, у которых семантически нет смысла различать оригинал и копию: целочисленные и плавающие, `bool`, `char`, разделяемые ссылки `&T`, неизменяемые сырые указатели, кортежи и массивы из Copy-полей, `Option<T>` и `Result<T, E>` если `T` и `E` тоже Copy.

Copy несовместим с Drop. Если у типа есть деструктор, компилятор не даст реализовать Copy, иначе один и тот же ресурс закрылся бы дважды. Поэтому `String`, `Vec`, `Box`, `File` всегда move-only.

```rust
#[derive(Copy, Clone)]
struct Point { x: f32, y: f32 }

fn main() {
 let p = Point { x: 1.0, y: 2.0 };
 let q = p; // copy
 let r = p; // тоже copy, p всё ещё валиден
 println!("{} {} {}", p.x, q.x, r.x);
}
```

Когда добавлять Copy. Только для маленьких POD-типов, где побайтовое копирование действительно дешёвое и семантически безопасное. Для `[u8; 4096]` Copy технически возможен, но любое присваивание скопирует 4 КБ - почти всегда это случайный пессимизм.

#### 3. Разница между &T и &mut T, какие правила заимствования действуют одновременно

`&T` - shared reference, `&mut T` - exclusive reference. На уровне типа это разные категории, а не модификатор изменяемости. `&mut` гарантирует эксклюзивный доступ: пока живёт `&mut T`, других ссылок на это значение не существует.

Правило XOR. В каждой точке программы либо одна `&mut T`, либо сколько угодно `&T`. Это инвариант, на котором держится noalias-оптимизация и отсутствие data race в безопасном коде.

```rust
fn main() {
 let mut v = vec![1, 2, 3];
 let r1 = &v;
 let r2 = &v; // несколько shared ок
 println!("{r1:?} {r2:?}");
 let m = &mut v; // r1 и r2 уже не используются благодаря NLL
 m.push(4);
}
```

Частая ловушка: итерация и мутация одновременно.

```rust
let mut v = vec![1, 2, 3];
for x in &v { // & v держит shared
 if *x == 2 { v.push(99); } // E0502
}
```

Чинится сбором изменений и применением после цикла, `v.retain`, или `Vec::drain_filter` в зависимости от задачи.

На уровне LLVM `&mut T` транслируется в указатель с атрибутом `noalias`, что даёт компилятору право переупорядочивать чтения и записи. Нарушение этого инварианта через unsafe приводит к UB, даже если код «выглядит правильно».

#### 4. Что такое лайфтайм и зачем нужны явные аннотации

Лайфтайм - область видимости, в течение которой ссылка гарантированно валидна. Каждая ссылка имеет лайфтайм, выведенный компилятором или указанный явно через `'a`. Лайфтаймы существуют только на этапе проверки типов, в рантайме их нет.

Явные аннотации нужны там, где компилятор не может однозначно связать лайфтаймы входов и выходов. Самый частый случай: функция возвращает ссылку, и есть несколько кандидатов на входе.

```rust
fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
 if a.len() >= b.len() { a } else { b }
}
```

Без `'a` компилятор не знает, привязать ли результат к `a`, к `b`, или к их пересечению. Аннотация говорит: возвращаемая ссылка живёт не дольше пересечения лайфтаймов входов.

Важно: аннотация не продлевает жизнь данных, она описывает уже существующие отношения. Если написать `'static` там, где значение живёт меньше, компилятор это поймает.

```rust
struct Parser<'src> { input: &'src str, pos: usize }
```

Тут `'src` нужен потому что структура держит ссылку, и компилятор обязан знать, что `Parser` не переживёт `input`.

Правило большого пальца: если у функции или структуры одна входная ссылка и одна выходная, аннотации не нужны (правило elision разруливает само). Если несколько входных ссылок и возвращается ссылка, аннотация почти всегда обязательна.

#### 5. Правила elision лайфтаймов

Elision - набор детерминированных правил, по которым компилятор вставляет лайфтаймы за вас. Применяется только в сигнатурах `fn` и `impl`-методах. К телам функций и к struct-определениям не применяется.

Правил три, применяются по порядку.

Первое: каждой входной ссылке без аннотации присваивается свой лайфтайм.

Второе: если ровно одна входная ссылка, её лайфтайм присваивается всем выходным.

Третье: если есть `&self` или `&mut self`, лайфтайм `self` присваивается всем выходным.

```rust
fn first(s: &str) -> &str { &s[..1] } // (1) и (2)
impl Cache { fn get(&self, key: &str) -> &str { /* */ } } // (1) и (3)
```

Когда elision не сработает. Несколько входных ссылок без `&self` - второе правило не применяется. Возвращается ссылка, не связанная ни с одним входом - тоже нужна аннотация (часто это `'static` для строковых литералов).

#### 6. Что такое 'static и почему это два разных смысла

`'static` встречается в двух разных контекстах, и их регулярно путают.

Первый: лайфтайм `'static` для ссылок. `&'static T` указывает на данные, живущие всё время работы программы. Строковые литералы имеют тип `&'static str` потому что лежат в `.rodata`. Также `'static` получают глобальные `static`-переменные и значения, помещённые в `Box::leak`.

```rust
let s: &'static str = "hello";
let leaked: &'static mut String = Box::leak(Box::new(String::from("dyn")));
```

Второй: bound `T: 'static`. Это значит «тип `T` не содержит нестатических ссылок». Сам объект может быть дропнут хоть сразу, но если внутри есть ссылка, она должна быть `'static`.

```rust
fn spawn<F: FnOnce() + Send + 'static>(f: F) { /* tokio::spawn */ }
```

Тут `'static` не значит «замыкание живёт вечно». Значит «замыкание не захватывает короткоживущих ссылок». `String` подходит под `T: 'static` потому что владеет своими данными.

Частая ошибка: объявляют `fn make() -> &'static str` и возвращают строку, собранную в рантайме. Решается возвратом `String`, или `Box::leak` с пониманием, что память не освободится.

#### 7. Что такое NLL и как работает borrow checker сейчас

NLL (Non-Lexical Lifetimes) появились в 2018 edition и фактически переписали borrow checker. До NLL лайфтайм заимствования совпадал с лексической областью видимости: ссылка считалась живой до закрывающей скобки, даже если фактически больше не использовалась. Это приводило к ложным отказам.

```rust
let mut v = vec![1, 2, 3];
let r = &v[0];
println!("{r}");
v.push(4); // до NLL ошибка, после NLL ок: r больше не используется
```

Сейчас borrow checker работает на MIR и считает лайфтайм заимствования по последней точке использования. Технически - анализ потока управления на CFG, где компилятор строит регионы и проверяет, не пересекаются ли несовместимые заимствования.

Следующий шаг - Polonius, реализация borrow checker на datalog. Он принимает несколько паттернов, которые NLL ещё отвергает, в первую очередь возврат ссылок через условные ветви.

если код выглядит корректным, но NLL не пропускает, помогает либо явное скоупирование в `{ ... }`, либо вынесение части кода в отдельную функцию, чтобы лайфтайм закрылся раньше.

#### 8. Что делает Box и когда он нужен

`Box<T>` - владеющий указатель в кучу. Внутри одно машинное слово - указатель на аллокацию из глобального аллокатора. При дропе `Box` вызывает деструктор `T` и возвращает память аллокатору.

Когда нужен.

Рекурсивные типы. `enum List { Cons(i32, Box<List>), Nil }`. Без `Box` размер был бы бесконечен, компилятор не сможет вычислить layout.

Большие значения. Перемещение `Box<[u8; 1_000_000]>` копирует одно слово, а не мегабайт.

Type erasure через trait object. `Box<dyn Trait>` хранит толстый указатель (data + vtable) и позволяет складывать в одну коллекцию разнородные реализации.

Возврат типа неизвестного размера. `fn make() -> Box<dyn Future<Output = u32>>` - компилятор не знает размер конкретного future, `Box` решает.

```rust
trait Shape { fn area(&self) -> f64; }
struct Circle(f64);
impl Shape for Circle {
 fn area(&self) -> f64 { std::f64::consts::PI * self.0 * self.0 }
}

let shapes: Vec<Box<dyn Shape>> = vec![Box::new(Circle(1.0))];
```

Чего `Box` не делает: не даёт shared ownership (для этого `Rc`/`Arc`), не даёт мутацию через shared (для этого `Cell`/`RefCell`), не делает thread-safe (это `Arc` и `Mutex`).

#### 9. Rc и Arc, в чем разница и когда что выбирать

`Rc<T>` и `Arc<T>` - shared-ownership через подсчёт ссылок. Разница в том, как обновляется счётчик.

`Rc` использует обычные неатомарные `usize`-операции. Дешевле на инкременте и декременте, но небезопасен для передачи между потоками. `Rc<T>` не реализует `Send` и не реализует `Sync`, попытка отправить его в `thread::spawn` даст ошибку компиляции.

`Arc` использует атомарные операции (`AtomicUsize` с `Relaxed` на инкременте и `Release`/`Acquire` на декременте). Реализует `Send` и `Sync` при `T: Send + Sync`. Атомарный декремент стоит дороже обычного, особенно при contention из многих потоков.

```rust
use std::sync::Arc;
let data = Arc::new(vec![1, 2, 3]);
let d2 = Arc::clone(&data);
std::thread::spawn(move || println!("{d2:?}"));
```

У каждого внутри два счётчика, strong и weak. Weak-ссылки нужны для разрыва циклов. `Rc::new_cyclic` и `Arc::new_cyclic` создают значение, которое может ссылаться на самого себя через `Weak`.

Когда что выбирать. По умолчанию однопоточно - `Rc`. Данные пересекают границу потоков - `Arc`. Внутри `tokio::spawn` замыкание должно быть `Send + 'static`, поэтому `Arc`. Иммутабельные read-heavy данные - `Arc` отлично работает. Нужна мутация - `Arc<Mutex<T>>` или `Arc<RwLock<T>>`.

Подводный камень: цикл из `Rc`/`Arc` - утечка. Если `A` владеет `Rc`, а `B` владеет `Rc<A>`, счётчики никогда не дойдут до нуля. Дерево с обратными ссылками родителей - классический случай, лечится `Weak` для родительских ссылок.

#### 10. Что такое interior mutability и какие типы её реализуют

Interior mutability - шаблон, при котором значение мутируется через shared-ссылку `&T`. Это нарушает обычное правило XOR на уровне API, но безопасность обеспечивается дополнительной проверкой: в рантайме или через системные примитивы.

`Cell<T>` для Copy-типов. Внутри `UnsafeCell`, API через `get`/`set`/`replace`, без выдачи ссылок наружу. Никакой проверки в рантайме, потому что без ссылок нет и aliasing-проблем.

`RefCell<T>` для произвольных типов. Раздаёт `Ref<T>` и `RefMut<T>` через `borrow` и `borrow_mut`, считает заимствования в рантайме. Нарушение XOR (например, два `borrow_mut` подряд) даёт панику. Не Sync, только для одного потока.

`Mutex<T>` и `RwLock<T>` - многопоточные аналоги. Блокируют поток, реализуют Sync.

`OnceCell<T>` и `LazyLock<T>` для однократной инициализации.

`atomic::Atomic*` для lock-free мутации Copy-типов.

```rust
use std::cell::RefCell;
use std::collections::HashMap;

struct Cache { map: RefCell<HashMap<String, String>> }
impl Cache {
 fn get_or_insert(&self, k: &str, v: String) -> String {
 let mut m = self.map.borrow_mut();
 m.entry(k.into()).or_insert(v).clone()
 }
}
```

Где нужно. Структуры, семантически иммутабельные снаружи, но кэширующие что-то внутри (memoization, ленивая инициализация). Графы и деревья с локальными обновлениями.

Все эти типы построены на `UnsafeCell` - единственном примитиве языка, через который компилятор разрешает получить `&mut T` из `&UnsafeCell<T>`. Прямое использование `UnsafeCell` требует unsafe и ручного соблюдения правил алиасинга.

#### 11. Что такое Cow и где он реально полезен

`Cow<'a, B>` (Clone-on-Write) - enum `Borrowed(&'a B) | Owned(B::Owned)`. Идея: пока изменения не нужны, держим shared-ссылку; как только нужно мутировать, делаем `to_mut`, который при необходимости клонирует данные в Owned-вариант.

Где применяется на практике.

Парсинг и нормализация. Если вход уже валидный, возвращаем `Cow::Borrowed(input)` без аллокации. Если нужно подправить, переходим в Owned.

```rust
use std::borrow::Cow;

fn normalize(s: &str) -> Cow<'_, str> {
 if s.contains('\r') { Cow::Owned(s.replace('\r', "")) }
 else { Cow::Borrowed(s) }
}
```

API, который может вернуть либо позаимствованную, либо собственную строку. `Path::to_string_lossy` возвращает `Cow<str>`: если путь валидный UTF-8 - `Borrowed`, иначе аллоцирует с заменой невалидных байтов.

Deserialization с zero-copy. `serde` поддерживает `Cow<'a, str>`: если входной буфер требует обработки эскейпов - Owned, если нет - Borrowed на исходный буфер.

Где не помогает. Если на горячем пути почти всегда нужна мутация, `Cow` только добавляет ветвление. Когда заведомо нужен `String`, его и берите.

#### 12. Что такое Drop и можно ли вызвать его руками

`Drop` - трейт с одним методом `fn drop(&mut self)`. Компилятор вызывает его в точке выхода значения из области владения. Деструктор гарантированно вызывается при нормальном завершении и при unwinding-панике (если panic=unwind), но не вызывается при `mem::forget` и при abort процесса.

Руками `drop()` метод трейта вызвать нельзя - это даст E0040. Если бы было можно, после ручного вызова компилятор всё равно вставил бы свой, и деструктор отработал бы дважды. Для досрочного освобождения есть свободная функция `std::mem::drop(x)`, которая просто принимает значение по move и роняет его на своём же закрытии скобок.

```rust
struct Guard;
impl Drop for Guard { fn drop(&mut self) { println!("bye"); } }

fn main() {
 let g = Guard;
 drop(g); // вызовет деструктор сейчас
 println!("after");
}
```

Детали. Порядок дропа полей структуры - в порядке объявления. Порядок дропа локальных переменных - в обратном порядке создания. Это критично для RAII-гардов: лок должен дропаться позже данных, которые он защищает.

В `Drop::drop` нельзя паниковать, если уже идёт паника: double panic ведёт к abort. Поэтому в деструкторах не вызывают `.unwrap` и не делают потенциально падающих операций.

Конфликт с move. После `drop(x)` биндинг инвалидирован, к нему уже не обратиться. И тип с `Drop` не может быть `Copy`.

#### 13. Move в замыканиях и Fn, FnMut, FnOnce

Замыкание - анонимный тип с реализацией одного из трёх трейтов: `Fn`, `FnMut` или `FnOnce`. Компилятор автоматически выбирает наиболее «лёгкий» из доступных, исходя из того, как замыкание использует захваченные переменные.

`FnOnce` вызывается ровно один раз, потому что забирает захваченные значения по move внутрь себя или внутрь вызова. `FnMut` вызывается многократно и может мутировать захваченные переменные, требует `&mut` к самому замыканию. `Fn` вызывается многократно и не мутирует, достаточно `&`.

Иерархия: `Fn: FnMut: FnOnce`. Если замыкание реализует `Fn`, оно автоматически и `FnMut`, и `FnOnce`.

```rust
let s = String::from("hi");
let f1 = || println!("{s}"); // Fn: захват по &
let mut v = vec![1];
let mut f2 = || v.push(2); // FnMut: захват по &mut
let f3 = move || drop(s); // FnOnce: потребляет s
```

Ключевое слово `move` форсирует захват по значению независимо от того, как используются переменные. Это нужно для `thread::spawn` и `tokio::spawn`, потому что замыкание должно быть `'static` и не может держать ссылок на стек породившего потока.

Подводный камень: `move` не делает замыкание `FnOnce` автоматически. Если внутри `move`-замыкания только читаются `Copy`-значения, оно останется `Fn`. Тип трейта определяется тем, что замыкание делает с захваченным, а `move` только меняет способ захвата.

#### 14. Что такое PhantomData и где его применять

`PhantomData<T>` - маркер нулевого размера, который говорит компилятору: «считай, что эта структура владеет или использует `T`, хотя физически его не хранит». Без хранения данных, но с эффектом на dropck, variance и auto traits.

Где это пригождается.

Привязка лайфтайма к структуре, которая держит сырой указатель. Без `PhantomData<&'a T>` компилятор не свяжет `'a` со структурой, и можно получить висящий указатель без жалоб от borrow checker.

```rust
struct Slice<'a, T> {
 ptr: *const T,
 len: usize,
 _marker: std::marker::PhantomData<&'a T>,
}
```

Type-state и типизированные ID. Разделить `Id<User>` и `Id<Order>`, хотя внутри обе `u64`. PhantomData делает их разными типами без накладных расходов.

```rust
use std::marker::PhantomData;
struct Id<T> { value: u64, _t: PhantomData<T> }
struct User; struct Order;
```

Контроль variance и Send/Sync. `PhantomData<*const T>` снимает `Send`/`Sync`, `PhantomData<fn() -> T>` делает тип ковариантным по `T`. Это инструменты для авторов unsafe-кода, которые знают, какую дисперсию они хотят.

Что эта штука не делает. `PhantomData<T>` не вызывает деструктор `T`, потому что значение не хранится. Если ваш тип логически владеет `T` и должен его дропать, нужен `PhantomData<T>` плюс корректная работа с dropck, либо хранение реального `T`.

#### 15. Borrow, AsRef, Deref, чем они отличаются

Все три позволяют получить ссылку, но решают разные задачи и имеют разные контракты.

`Deref` - «прозрачное разыменование». Реализуя `Deref<Target = T>`, вы заявляете, что ваш тип семантически является `T`. Компилятор применяет deref coercion: `&Box<T>` неявно становится `&T`, `&String` становится `&str`. Метод-резолюция тоже идёт по deref-цепочке. Реализуется только для smart pointer-подобных типов; реализация для произвольных контейнеров считается анти-паттерном.

```rust
let s = String::from("hi");
let r: &str = &s; // deref coercion
```

`AsRef<T>` - «дешёвое преобразование ссылки в ссылку». Не требует identity: `AsRef<str>` есть у `String`, у `&str`, у `PathBuf`. Используется в обобщённых API: `fn read<P: AsRef<Path>>(p: P)` принимает что угодно, что превращается в `&Path`.

`Borrow<T>` похож на `AsRef`, но с дополнительным контрактом: `Hash`, `Eq`, `Ord` у `Self` и у `Borrow::Target` должны давать одинаковые результаты. Это нужно для `HashMap::get`: ключ типа `String` ищется по `&str`, и хэш строки должен совпадать с хэшем её `&str`-представления.

```rust
use std::collections::HashMap;
let mut m: HashMap<String, i32> = HashMap::new();
m.insert("a".into(), 1);
m.get("a"); // &str: работает через Borrow<str> для String
```

Когда что выбирать. Smart pointer - `Deref`. Принять любое строкоподобное в API - `AsRef<str>` или `AsRef<Path>`. Ключи коллекций с альтернативным lookup - `Borrow`.

### Типы, трейты, обобщения

#### 16. Чем структура отличается от enum

Структура это произведение типов. Все поля присутствуют одновременно. Enum это сумма типов. В любой момент активен ровно один вариант. Эту разницу важно понимать, потому что в Rust enum полноценный алгебраический тип, не как в C. Каждый вариант может нести произвольные данные. Память enum занимает по размеру самого большого варианта плюс дискриминант. Компилятор умеет ужимать представление, если есть niche, например None в Option<&T> кодируется нулевым указателем.

```rust
enum Shape {
 Circle(f64),
 Rect { w: f64, h: f64 },
}

fn area(s: &Shape) -> f64 {
 match s {
 Shape::Circle(r) => std::f64::consts::PI * r * r,
 Shape::Rect { w, h } => w * h,
 }
}

fn main() { println!("{}", area(&Shape::Rect { w: 2.0, h: 3.0 })); }
```

match заставляет покрыть все варианты, и забыть про новый случай при расширении enum компилятор не даст.

#### 17. Что такое трейт и чем он отличается от интерфейса в Java

Трейт это набор методов и ассоциированных элементов, который тип может реализовать. От интерфейсов в Java отличается тем, что реализацию можно писать в другом модуле, чем сам тип, при условии соблюдения orphan rule. Трейты поддерживают дефолтные методы, ассоциированные типы и константы, могут быть обобщенными. Диспетчеризация по умолчанию статическая, через мономорфизацию, но можно сделать динамическую через dyn Trait.

```rust
trait Greet {
 fn name(&self) -> &str;
 fn hello(&self) { println!("hi {}", self.name()); }
}

struct Cat;
impl Greet for Cat { fn name(&self) -> &str { "cat" } }

fn main() { Cat.hello(); }
```

Дефолтный hello переиспользуется любым типом, который дал свою name.

#### 18. Статическая и динамическая диспетчеризация, плюсы и минусы

Статическая диспетчеризация это generics с мономорфизацией. Компилятор генерирует свою копию функции под каждый конкретный тип. Быстрее в рантайме, заинлайнено, но раздувает бинарник и увеличивает время компиляции. Динамическая диспетчеризация это dyn Trait. Используется vtable, вызов через указатель. Бинарник меньше, типы можно смешивать в одном Vec<Box<dyn Trait>>, но есть стоимость косвенного вызова и невозможность инлайна.

```rust
trait Op { fn run(&self) -> i32; }
struct A; impl Op for A { fn run(&self) -> i32 { 1 } }
struct B; impl Op for B { fn run(&self) -> i32 { 2 } }

fn sum_static<T: Op>(x: &T, y: &T) -> i32 { x.run() + y.run() }
fn sum_dyn(ops: &[Box<dyn Op>]) -> i32 { ops.iter().map(|o| o.run()).sum() }
```

Выбор в проде такой. Если типы известны и набор маленький, generics. Если плагины, гетерогенные коллекции, конфигурация в рантайме, dyn.

#### 19. Что такое object safety и почему не любой трейт может быть dyn

Чтобы трейт можно было использовать как dyn Trait, он должен быть object safe. Главные ограничения такие. Методы не принимают и не возвращают Self по значению, не используют дженерики, не имеют where Self: Sized без отдельного маркера. Self не появляется в ассоциированных константах. Причина в том, что для vtable нужен фиксированный набор слотов с известными сигнатурами. Если бы метод принимал Self, размер аргумента зависел бы от конкретного типа, и универсальный vtable стал бы невозможен.

```rust
trait Bad { fn make() -> Self; } // не object safe
trait Good { fn name(&self) -> &str; } // object safe

fn use_good(x: &dyn Good) { println!("{}", x.name()); }
```

Если очень хочется иметь и dyn, и generic метод, обычно разделяют трейт на два или используют where Self: Sized для отдельных методов.

#### 20. Ассоциированные типы и дженерик параметры трейта, в чем разница

Генерик параметр трейта позволяет реализовать трейт несколько раз для одного типа с разными параметрами. Ассоциированный тип фиксируется в реализации, один тип это одна Item. Iterator имеет ассоциированный Item, потому что для одного типа естественно одно Item. From наоборот имеет generic параметр, потому что один тип может конвертироваться из многих других.

```rust
trait Counter { type Item; fn next(&mut self) -> Option<Self::Item>; }

struct UpTo { i: u32, end: u32 }
impl Counter for UpTo {
 type Item = u32;
 fn next(&mut self) -> Option<u32> {
 if self.i < self.end { self.i += 1; Some(self.i - 1) } else { None }
 }
}
```

Если бы Item был обычным параметром, в коде пришлось бы постоянно его уточнять, и эргономика провисла.

#### 21. Что такое orphan rule и зачем он нужен

Правило сирот гласит, что реализовать трейт для типа можно только если либо трейт, либо тип определены в том же крейте. Это нужно, чтобы две сторонние библиотеки не сделали независимо несовместимые реализации одного и того же трейта для одного и того же типа. Когерентность системы трейтов держится именно на этом правиле. Обход обычно делают через newtype.

```rust
use std::fmt::Display;

struct Wrap(Vec<i32>);

impl Display for Wrap {
 fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
 write!(f, "{:?}", self.0)
 }
}
```

Wrap локальный, поэтому реализация Display для него разрешена.

#### 22. Что такое newtype и зачем он применяется

Newtype это структура с одним полем, оборачивающая другой тип. Применений много. Соблюдение orphan rule, типобезопасность доменных значений, скрытие представления, разные реализации трейтов для одного базового типа. В рантайме newtype бесплатен, потому что layout совпадает с внутренним типом, и часто компилятор инлайнит обертку полностью.

```rust
struct Meters(f64);
struct Seconds(f64);

fn speed(d: Meters, t: Seconds) -> f64 { d.0 / t.0 }

fn main() { println!("{}", speed(Meters(100.0), Seconds(9.58))); }
```

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

#### 23. Что такое derive и какие трейты обычно автоматически выводятся

#[derive(...)] это атрибут, который запускает соответствующий процедурный макрос и генерирует реализацию трейта. Стандартные derivable трейты это Debug, Clone, Copy, PartialEq, Eq, Hash, Default, PartialOrd, Ord. Они работают, если у всех полей структуры или вариантов enum уже есть нужная реализация. Помимо стандартных, derive часто используют для Serialize, Deserialize, thiserror::Error, strum.

```rust
#[derive(Debug, Clone, PartialEq, Eq, Hash, Default)]
struct Point { x: i32, y: i32 }

fn main() {
 let p = Point::default();
 println!("{:?}", p.clone());
}
```

Derive это про эргономику и про защиту от ошибок при рефакторинге. Добавили поле, и все реализации обновились автоматически.

#### 24. Что такое impl Trait в позиции возврата и в позиции аргумента

В позиции возврата impl Trait означает один конкретный, но непоименованный тип, реализующий трейт. Используется чаще всего для возврата итераторов и замыканий, чтобы не писать длинные типы. Тип фиксируется внутри функции и одинаков для всех вызовов. В позиции аргумента impl Trait это просто короткая запись для дженерика, эквивалентно T: Trait.

```rust
fn iter_evens(v: &[i32]) -> impl Iterator<Item = &i32> {
 v.iter().filter(|x| *x % 2 == 0)
}

fn log(item: impl std::fmt::Display) { println!("{}", item); }
```

С возвращаемым impl Trait нужно помнить, что лайфтаймы захваченных аргументов попадают в скрытый тип. С 2024 edition правила захвата стали более явными.

#### 25. dyn Trait в полях структуры, что нужно знать

dyn Trait это unsized тип. Положить его в поле структуры напрямую нельзя, нужен указатель. Чаще всего это Box<dyn Trait>, реже &dyn Trait, Rc или Arc. При выборе важно решить, кто владеет объектом. Если структура живет долго и должна владеть, обычно Box или Arc. Если структура только использует чужой объект, &dyn с лайфтаймом.

```rust
trait Logger { fn log(&self, msg: &str); }

struct App { logger: Box<dyn Logger + Send + Sync> }

struct Console;
impl Logger for Console { fn log(&self, m: &str) { println!("{}", m); } }

fn main() {
 let app = App { logger: Box::new(Console) };
 app.logger.log("ok");
}
```

Типичный паттерн внедрения зависимостей. Send и Sync добавлены, чтобы App можно было передавать между потоками.

#### 26. Что такое Sized, ?Sized и зачем это

Sized это трейт, который реализуют все типы с известным на этапе компиляции размером. Это i32, String, &T, Box<T>. Не Sized это str, [T], dyn Trait. С такими типами нельзя работать по значению, только через указатель. По умолчанию у любого дженерика стоит неявное T: Sized. Если нужно принимать DST, явно пишут T: ?Sized.

```rust
fn print_ref<T: ?Sized + std::fmt::Debug>(x: &T) {
 println!("{:?}", x);
}

fn main() {
 print_ref::<str>("hello");
 print_ref::<[i32]>(&[1, 2, 3]);
}
```

Без ?Sized такой код не собрался бы для str и среза.

#### 27. Что такое where clause и когда она нужнее, чем inline ограничения

Where позволяет описывать ограничения отдельно от списка параметров. Это удобно, когда ограничений много или они сложные. Например, ограничение на ассоциированный тип. T: Iterator, T::Item: Display. Записать это в угловых скобках громоздко. where в большом коде еще полезен тем, что выравнивает ограничения вертикально и упрощает диффы.

```rust
use std::fmt::Display;

fn print_all(iter: I) where I: IntoIterator, I::Item: Display {
 for x in iter { println!("{}", x); }
}

fn main() { print_all(vec!["a", "b"]); }
```

При усложнении сигнатур where почти всегда читается лучше, чем длинная строка в угловых скобках.

#### 28. Что такое coherence и блансировка реализаций

Когерентность это свойство системы трейтов, при котором для каждой пары тип трейт существует не более одной реализации, видимой во всей программе. Без когерентности один и тот же вызов в разных местах мог бы попадать в разные реализации, и поведение программы стало бы непредсказуемым. На уровне правил это поддерживается orphan rule и запретом перекрывающихся реализаций. Specialization, который частично позволяет иметь более специфичные реализации, до сих пор в стабильном виде не доехал именно по этой причине.

Компилятор отказывается принимать любую пару реализаций, которые потенциально могут пересекаться.

```rust
// Не соберется, если раскомментировать обе реализации.
// trait Foo {}
// impl<T> Foo for T {}
// impl Foo for i32 {}
```

Комментарий простой. Если хочется специализировать, сейчас приходится обходить это вручную через mini specialization паттерны.

#### 29. Что такое supertrait и зачем он бывает нужен

Supertrait это требование, что любой тип, реализующий данный трейт, должен также реализовывать другой. Записывается как trait Child: Parent. Это позволяет вызывать методы родителя на &dyn Child и сужает множество реализаций. Полезно, когда родительский трейт дает базовые методы, а дочерний расширяет логику.

```rust
use std::fmt::Display;

trait Pretty: Display {
 fn pretty(&self) -> String { format!("=> {}", self) }
}

impl Pretty for i32 {}

fn main() { println!("{}", 7i32.pretty()); }
```

В методе pretty можно использовать любой метод Display прямо через self.

#### 30. Что такое blanket implementation и где она применяется в стандартной библиотеке

Blanket impl это реализация трейта для всех типов, удовлетворяющих какому то ограничению. Самые известные примеры из стандартной библиотеки это impl<T: Display> ToString for T и impl<T, U> Into for T where U: From<T>. Первый автоматически дает метод to_string для всего, что умеет печататься. Второй автоматически дает Into, как только написана From. Это очень мощный механизм, но он же конфликтует с orphan rule, потому что после blanket добавить ручную реализацию для пересекающегося типа уже нельзя.

```rust
struct Celsius(f64);
struct Fahrenheit(f64);

impl From<Celsius> for Fahrenheit {
 fn from(c: Celsius) -> Self { Fahrenheit(c.0 * 1.8 + 32.0) }
}

fn main() {
 let f: Fahrenheit = Celsius(100.0).into(); // into получено через blanket
 println!("{}", f.0);
}
```

Здесь руками написана только From, а Into подъехала бесплатно через стандартный blanket.

### Конкурентность и параллелизм

#### 31. Send и Sync, в чем разница и как они выводятся

Send означает, что значение типа можно безопасно передать в другой поток. Sync означает, что &T можно безопасно делить между потоками, то есть T реализует Sync, если &T реализует Send. Оба трейта auto traits, компилятор сам выводит реализацию по полям. Не Send Rc, потому что счетчик не атомарный. Не Send и не Sync сырые указатели в обертках вроде Cell, потому что мутируют через shared ссылку без синхронизации.

```rust
use std::sync::Arc;
use std::thread;

fn main() {
 let v = Arc::new(vec![1, 2, 3]);
 let v2 = v.clone();
 thread::spawn(move || println!("{:?}", v2)).join().unwrap();
}
```

Если заменить Arc на Rc, компилятор откажется собирать, потому что Rc не Send.

#### 32. Чем Mutex отличается от RwLock и когда какой выбирать

Mutex дает эксклюзивный доступ. В любой момент только один поток внутри секции. RwLock разрешает либо одного писателя, либо несколько читателей одновременно. RwLock дороже на вход и выход, и при коротких критических секциях обычно проигрывает Mutex даже на читающей нагрузке. Имеет смысл, когда читатели держат лок долго, а писатели редки.

```rust
use std::sync::RwLock;

fn main() {
 let lock = RwLock::new(0);
 {
 let r1 = lock.read().unwrap();
 let r2 = lock.read().unwrap();
 println!("{} {}", *r1, *r2);
 }
 *lock.write().unwrap() = 5;
}
```

Из практики. Если не уверены, начинать с Mutex. Менять на RwLock только после измерения, и не в любом стиле, а с учетом приоритета писателей, иначе можно получить starvation.

#### 33. Что такое poisoning у Mutex и как с ним жить

Если поток упал с паникой, удерживая Mutex, лок становится отравленным. Все последующие попытки lock возвращают Err. Это сделано, чтобы случайно не работать с потенциально невалидным состоянием. Часто разумно прочитать данные через into_inner или PoisonError::into_inner и продолжить, если инвариант не нарушен. В новых проектах parking_lot::Mutex обычно предпочитают, у него нет poisoning и он быстрее.

```rust
use std::sync::Mutex;

fn main() {
 let m = Mutex::new(0);
 let _ = std::panic::catch_unwind(|| {
 let _g = m.lock().unwrap();
 panic!("boom");
 });
 match m.lock() {
 Ok(g) => println!("{}", *g),
 Err(p) => println!("poisoned, value = {}", *p.into_inner()),
 }
}
```

Ключ в том, что Rust не дает молча проигнорировать факт паники под локом.

#### 34. Channel в std::sync::mpsc, его особенности

Канал mpsc это многопроизводитель один потребитель. Передача по значению, отправитель Send, приемник Send но не Sync. Каналы строятся вокруг неограниченной очереди. Это удобно, но опасно. Если получатель медленнее отправителей, память растет. На практике часто используют crossbeam-channel и tokio mpsc, у них есть bounded варианты, select, поддержка отмены.

```rust
use std::sync::mpsc;
use std::thread;

fn main() {
 let (tx, rx) = mpsc::channel();
 for i in 0..3 {
 let tx = tx.clone();
 thread::spawn(move || tx.send(i).unwrap());
 }
 drop(tx);
 for v in rx { println!("{}", v); }
}
```

Цикл for v in rx завершается, когда все клоны tx уничтожены. Поэтому важно сбросить исходный tx, иначе будет дедлок.

#### 35. Что такое scoped threads и зачем они появились в стандартной библиотеке

До стабилизации std::thread::scope для передачи ссылок в поток приходилось либо использовать Arc, либо crate crossbeam. Scoped threads гарантируют, что все потоки внутри scope завершатся до выхода из него, поэтому компилятор разрешает заимствовать стек вызывающего без 'static. Это убрало целый класс лишних аллокаций и упростило код.

```rust
use std::thread;

fn main() {
 let data = vec![1, 2, 3, 4];
 thread::scope(|s| {
 s.spawn(|| println!("{:?}", &data[..2]));
 s.spawn(|| println!("{:?}", &data[2..]));
 });
}
```

После scope data все еще доступна. Никаких клонов и Arc.

#### 36. Atomic типы, что такое memory ordering и какие порядки бывают

Atomic типы дают неблокирующие операции с явным memory ordering. Доступные порядки это Relaxed, Acquire, Release, AcqRel, SeqCst. Relaxed гарантирует только атомарность самой операции. Acquire запрещает реордеринг последующих чтений выше себя. Release запрещает реордеринг предыдущих записей ниже себя. SeqCst дает глобальный порядок. На практике большинство кода обходится парой Acquire и Release для flag паттернов, а SeqCst используется, когда лень думать, либо когда действительно нужен тотальный порядок.

```rust
use std::sync::atomic::{AtomicUsize, Ordering};
use std::thread;

static CNT: AtomicUsize = AtomicUsize::new(0);

fn main() {
 let h: Vec<_> = (0..4).map(|_| thread::spawn(|| {
 for _ in 0..1000 { CNT.fetch_add(1, Ordering::Relaxed); }
 })).collect();
 for t in h { t.join().unwrap(); }
 println!("{}", CNT.load(Ordering::Relaxed));
}
```

Для простого счетчика Relaxed достаточно, потому что важна только финальная сумма, а не порядок инкрементов.

#### 37. Что такое гонка данных и чем она отличается от race condition

Гонка данных это конкретная ситуация, когда два потока обращаются к одной памяти без синхронизации, и хотя бы один пишет. В безопасном Rust таких гонок нет благодаря системе типов и трейтам Send Sync. Race condition это более широкое понятие, логическая гонка по времени. Например, проверили условие, потом что то сделали, а между этими шагами другой поток уже изменил состояние. Гонок данных Rust не допустит, race condition в логике вполне может быть.

```rust
use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
 let m = Arc::new(Mutex::new(false));
 let m2 = m.clone();
 let h = thread::spawn(move || {
 let mut g = m2.lock().unwrap();
 if !*g { *g = true; }
 });
 h.join().unwrap();
 println!("{}", *m.lock().unwrap());
}
```

Лок здесь решает не гонку данных, а именно атомарность пары чтение запись.

#### 38. Что такое deadlock и как его избегать в Rust

Дедлок это ситуация, когда несколько потоков ждут друг друга по кругу и ни один не может продвинуться. Классически возникает при захвате нескольких локов в разном порядке. Базовый рецепт. Всегда брать локи в одном фиксированном порядке. Минимизировать критические секции. По возможности использовать try_lock и таймауты. В асинхронном коде дедлок легко получить, удерживая лок через await. Лучше явно отпустить лок перед await.

```rust
use std::sync::Mutex;

fn safe(m: &Mutex<i32>) -> i32 {
 let v = { let g = m.lock().unwrap(); *g };
 v + 1
}

fn main() {
 let m = Mutex::new(10);
 println!("{}", safe(&m));
}
```

Лок берется в блоке и сразу отпускается. Дальнейшая логика выполняется без удерживания.

#### 39. Rayon, как он работает и где его уместно применять

Rayon это библиотека параллельной обработки данных с work stealing. Главная сильная сторона это адаптер par_iter, который превращает обычный итератор в параллельный. Под капотом он рекурсивно делит работу на пары и распределяет задачи между потоками пула. Хорошо подходит для CPU bound задач над коллекциями. Плохо подходит для IO, для смешанных рабочих нагрузок с блокировками и для задач с сильной зависимостью между шагами.

```rust
use rayon::prelude::*;

fn main() {
 let sum: u64 = (1u64..=1_000_000).into_par_iter().map(|x| x * x).sum();
 println!("{}", sum);
}
```

Если в map встретится блокирующий вызов, поток пула будет занят, и parallelism деградирует. Это типичная ловушка при смешении rayon с синхронным IO.

#### 40. Что такое work stealing и почему он эффективен

Work stealing это стратегия планирования, при которой каждый поток имеет собственную очередь задач и берет работу с ее головы. Когда у потока закончились свои задачи, он крадет задачу с хвоста очереди другого потока. Это снижает конкуренцию за общую очередь, дает хорошую локальность, потому что свежие задачи берутся свои, и при этом распределяет нагрузку. На этом принципе работают rayon, tokio multi thread, async-std.

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

#### 41. Что такое thread pool и почему ручное spawn не всегда хорошая идея

Создание потока операции не бесплатно. Это сискол, стек, регистрация в ядре. Если задачи короткие, тратить отдельный поток на каждую расточительно. Thread pool создает потоки заранее и переиспользует их. В Rust типовые решения это rayon::ThreadPool, tokio::runtime, threadpool. Спавн потока руками оправдан для долгоживущих сущностей, например для фонового логгера или для отдельного цикла обработки IO.

```rust
use rayon::ThreadPoolBuilder;

fn main() {
 let pool = ThreadPoolBuilder::new().num_threads(4).build().unwrap();
 let r = pool.install(|| (0..100).into_iter().sum::<i32>());
 println!("{}", r);
}
```

Явный пул удобен, когда нужно отделить горячие задачи от фоновых.

#### 42. Что такое barrier и когда он нужен

Барьер синхронизирует группу потоков. Все потоки доходят до барьера и ждут, пока не подойдут все остальные, после чего проходят дальше одновременно. Используется в симуляциях по шагам, в параллельных алгоритмах, где фаза вычисления должна полностью закончиться до начала следующей. В Rust есть std::sync::Barrier.

```rust
use std::sync::{Arc, Barrier};
use std::thread;

fn main() {
 let b = Arc::new(Barrier::new(3));
 let mut h = vec![];
 for i in 0..3 {
 let b = b.clone();
 h.push(thread::spawn(move || {
 println!("{} before", i);
 b.wait();
 println!("{} after", i);
 }));
 }
 for t in h { t.join().unwrap(); }
}
```

Вывод гарантирует, что все before напечатаются до любого after.

#### 43. Что такое condvar и когда он лучше, чем busy wait

Condvar это условная переменная. Поток, удерживая лок, ждет условие через wait. На время wait лок отпускается. Другой поток меняет состояние и вызывает notify_one или notify_all. После пробуждения wait автоматически снова берет лок. Это правильный способ ждать события, без сжигания процессора в цикле проверки.

```rust
use std::sync::{Arc, Condvar, Mutex};
use std::thread;

fn main() {
 let pair = Arc::new((Mutex::new(false), Condvar::new()));
 let pair2 = pair.clone();
 thread::spawn(move || {
 let (m, cv) = &*pair2;
 let mut g = m.lock().unwrap();
 *g = true;
 cv.notify_one();
 });
 let (m, cv) = &*pair;
 let mut g = m.lock().unwrap();
 while !*g { g = cv.wait(g).unwrap(); }
 println!("started");
}
```

Проверка в while нужна потому, что бывают spurious wakeups, и одного wait недостаточно.

#### 44. Что такое spinlock и когда он оправдан

Spinlock это лок, который вместо блокировки потока крутится в цикле проверки. Имеет смысл только тогда, когда критическая секция очень короткая и переключение контекста было бы дороже самого ожидания. В прикладном коде это редкость. В драйверах и низкоуровневых либах встречается. В Rust стандартного spinlock нет, есть параметризованные реализации в crate spin. Но в большинстве случаев правильный ответ это parking_lot::Mutex, который сам решает, спинить или парковать.

#### 45. Что такое thread local и где он реально нужен

Thread local это значение, у которого свой экземпляр в каждом потоке. В Rust это макрос thread_local! и тип LocalKey. Полезен для аллокаторов, для пер потокового кэша, для трассировки, для случайных генераторов. Важно понимать, что данные thread local не Send. Если попытаться унести из них что то в другой поток, надо клонировать.

```rust
use std::cell::RefCell;

thread_local! {
 static COUNTER: RefCell<u64> = RefCell::new(0);
}

fn bump() { COUNTER.with(|c| *c.borrow_mut() += 1); }

fn main() {
 bump(); bump();
 COUNTER.with(|c| println!("{}", c.borrow()));
}
```

Это частый паттерн для статистики и для тестового хука вместо глобального состояния.

### Async и runtime

#### 46. Что такое async fn и во что он превращается компилятором

async fn это синтаксический сахар над функцией, возвращающей impl Future. Тело функции трансформируется в стейт машину. Каждое .await это точка приостановки. Локальные переменные, живущие через .await, превращаются в поля стейт машины. Сама функция при вызове не делает работу, а возвращает фьючу. Работа начинается только когда фьючу опрашивает рантайм.

```rust
async fn add(a: u32, b: u32) -> u32 { a + b }

#[tokio::main]
async fn main() {
 let f = add(1, 2); // ничего еще не вычислено
 let r = f.await; // только сейчас полл и результат
 println!("{}", r);
}
```

Эта ленивость отличает Rust от языков, где async eager.

#### 47. Что такое Future и как работает poll

Future это трейт с одним методом poll. Поллер передает Context с Waker. Реализация делает шаг вперед и возвращает Poll::Ready, если работа закончена, или Poll::Pending, если нужно подождать. Если вернули Pending, реализация обязана где то сохранить waker и вызвать его, когда сможет продвинуться. Иначе фьюча зависнет. Рантайм не опрашивает фьючи в цикле, он реагирует на пробуждения.

```rust
use std::future::Future;
use std::pin::Pin;
use std::task::{Context, Poll};

struct Yield(bool);
impl Future for Yield {
 type Output = ();
 fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<()> {
 if self.0 { Poll::Ready(()) } else {
 self.0 = true;
 cx.waker().wake_by_ref();
 Poll::Pending
 }
 }
}
```

Yield один раз отдает управление и сразу будит сам себя. Простой способ дать рантайму прокрутить очередь.

#### 48. Tokio и async-std, в чем разница и что выбирать

Tokio это де факто стандарт. Большой набор примитивов, мощный планировщик, экосистема. async-std ставил целью повторить API стандартной библиотеки, но в практике почти весь крупный код в индустрии написан под tokio. Сейчас async-std в значительной мере legacy. Выбор простой. Если проект не имеет жестких требований, берется tokio. Если хочется минимального рантайма для embedded, есть smol, embassy.

#### 49. Что такое executor и reactor в async

Executor отвечает за то, чтобы поллить фьючи, когда их нужно поллить. Reactor отвечает за регистрацию событий ввода вывода в ядре и за пробуждение wakers, когда событие пришло. В tokio это реализовано через mio. Когда сокет становится готов, mio будит соответствующий waker, executor добавляет таску в очередь, и фьюча получает следующий polл.

Понимать эту пару важно, потому что многие странности async объясняются разделением ответственности. Если фьюча не двигается, либо ее не разбудили, либо executor не дошел до очереди.

#### 50. Кооперативная многозадачность и почему нельзя блокировать поток в async

В async коде один поток выполняет много задач. Пока задача не отдала управление через await, никакая другая не выполняется на этом потоке. Если внутри async fn вызвать std::thread::sleep или сделать тяжелый sync IO, остальные задачи на этом же рабочем потоке встанут. В tokio есть spawn_blocking, который отправляет работу на отдельный пул блокирующих потоков. Это правильный путь для CPU bound или для синхронных API.

```rust
#[tokio::main]
async fn main() {
 let r = tokio::task::spawn_blocking(|| heavy()).await.unwrap();
 println!("{}", r);
}

fn heavy() -> u64 { (0..1_000_000u64).sum() }
```

Логика простая. Все, что может занять больше микросекунды без await, отправляется в spawn_blocking.

#### 51. Что такое tokio::select и какие у него подводные камни

select позволяет ждать одновременно несколько фьюч и продолжить, как только одна из них готова. Остальные фьючи дропаются. Это и есть основная ловушка. Если внутри ветки уже была выполнена часть работы с побочным эффектом, дропнутая фьюча не доведет работу до конца. Поэтому при использовании select важно либо использовать cancel safe примитивы, либо явно сохранять состояние через future::pin и biased.

```rust
use tokio::time::{sleep, Duration};

#[tokio::main]
async fn main() {
 tokio::select! {
 _ = sleep(Duration::from_millis(50)) => println!("timeout"),
 _ = async { sleep(Duration::from_millis(100)).await; } => println!("inner"),
 }
}
```

Здесь сработает таймаут, а вторая ветка будет отменена.

#### 52. Cancel safety, что это и почему важно

Cancel safety означает, что фьюча может быть дропнута на любом await без нарушения инвариантов. Многие операции tokio cancel safe, например чтение из канала. Многие не cancel safe, например AsyncReadExt::read_exact, который при отмене может оставить буфер частично прочитанным. В коде, который использует select, надо знать про cancel safety используемых API. В документации tokio это явно отмечено.

#### 53. Что такое spawn и join в tokio

tokio::spawn отправляет фьючу на исполнение в рантайм и возвращает JoinHandle. Сама задача начинает работать немедленно. JoinHandle это фьюча с результатом. Через await на хендле можно дождаться завершения и забрать значение. Если хендл уронить, задача продолжит работать в фоне. Чтобы прервать, можно вызвать abort.

```rust
#[tokio::main]
async fn main() {
 let h = tokio::spawn(async { 42 });
 println!("{}", h.await.unwrap());
}
```

Задача в spawn должна быть 'static и Send для multi thread рантайма. Для single thread достаточно 'static.

#### 54. Что такое JoinSet и зачем он нужен

JoinSet это структура для управления группой задач. Позволяет ждать завершения любого из них через join_next, отменять все через shutdown, ограничивать число параллельно работающих. По сравнению с FuturesUnordered удобнее именно для tokio задач, потому что хранит JoinHandle и корректно обрабатывает abort.

```rust
use tokio::task::JoinSet;

#[tokio::main]
async fn main() {
 let mut set = JoinSet::new();
 for i in 0..5 { set.spawn(async move { i * i }); }
 while let Some(r) = set.join_next().await {
 println!("{}", r.unwrap());
 }
}
```

Это типовой паттерн fan out fan in.

#### 55. Что такое async trait и почему он нетривиален

async fn в трейтах долгое время не было, потому что Future это разный тип у каждой реализации. Сейчас в стабильном Rust async fn в трейтах работает напрямую, но с ограничениями для dyn. Для dyn trait сейчас используют либо макрос async_trait, либо вручную возвращают Box<dyn Future>. async_trait делает примерно это под капотом, добавляя аллокацию на каждый вызов. Для горячих путей это критично.

```rust
use async_trait::async_trait;

#[async_trait]
trait Store {
 async fn get(&self, key: &str) -> Option<String>;
}

struct Mem;
#[async_trait]
impl Store for Mem {
 async fn get(&self, _k: &str) -> Option<String> { Some("v".into()) }
}
```

Если динамическая диспетчеризация не нужна, лучше использовать обычный async fn в трейте и не платить за box.

#### 56. Backpressure и как его делать в async

Backpressure это давление потребителя на производителя. Без него быстрый продюсер забивает память. В асинхронных конвейерах backpressure реализуется через bounded каналы и через ограничение параллелизма. В tokio есть mpsc::channel с capacity, у него send становится фьючей, которая ждет, пока в очереди освободится место. Это автоматически тормозит продюсера.

```rust
use tokio::sync::mpsc;

#[tokio::main]
async fn main() {
 let (tx, mut rx) = mpsc::channel::<i32>(8);
 tokio::spawn(async move {
 for i in 0..100 { tx.send(i).await.unwrap(); }
 });
 while let Some(v) = rx.recv().await { println!("{}", v); }
}
```

Если получатель медленный, send в задаче будет ждать. Память не растет бесконтрольно.

#### 57. Streams в async, что это и где применяются

Stream это асинхронный аналог Iterator. Метод poll_next возвращает Poll<Option<Item>>. Стримы используются для обработки потоков сообщений, событий, чанков из сети, строк из файла. В крейтах futures и tokio_stream есть набор адаптеров map filter try_next chunks throttle.

```rust
use tokio_stream::{self as stream, StreamExt};

#[tokio::main]
async fn main() {
 let mut s = stream::iter(vec![1, 2, 3, 4, 5]).filter(|x| x % 2 == 0);
 while let Some(v) = s.next().await { println!("{}", v); }
}
```

Стримы хорошо ложатся на любую event driven архитектуру. Каждый шаг ленивый, кроме того, что нужно для прокачки следующего элемента.

#### 58. Что такое pin_project и зачем он нужен

Когда пишешь свою фьючу или стрим со сложной структурой, поля надо проектировать с учетом Pin. Какие то поля должны оставаться запиненными, какие то нет. pin_project это макрос, который генерирует безопасный API доступа к полям без unsafe. Без него пришлось бы писать вручную через Pin::map_unchecked_mut, а это легко превращается в UB.

```rust
use pin_project::pin_project;
use std::pin::Pin;
use std::future::Future;
use std::task::{Context, Poll};

#[pin_project]
struct Then<F> { #[pin] fut: F, n: u32 }

impl<F: Future<Output = u32>> Future for Then<F> {
 type Output = u32;
 fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<u32> {
 let this = self.project();
 match this.fut.poll(cx) {
 Poll::Ready(v) => Poll::Ready(v + *this.n),
 Poll::Pending => Poll::Pending,
 }
 }
}
```

project дает Pin<&mut F> для запиненного поля и &mut u32 для обычного. Никакого unsafe в пользовательском коде.

#### 59. Что такое executor budget в tokio и как его исчерпание влияет на код

Tokio начисляет каждой задаче бюджет в poll операциях. Когда задача исчерпала бюджет, кооперативный yield заставляет ее отдать управление, даже если она готова продолжить. Это защищает от ситуации, когда одна тяжелая задача занимает рабочий поток. Если задача делает много синхронной работы между awaits, бюджет тратится медленно, и можно случайно стать тем самым горячим воркером. Решение либо явные tokio::task::yield_now, либо вынесение в spawn_blocking.

#### 60. Что такое LocalSet и когда он нужен

LocalSet позволяет запускать !Send фьючи на одном потоке. Используется для задач, чьи внутренности нельзя двигать между потоками, типичный пример это интеграция с библиотеками, которые держат не Send состояние. В multi thread рантайме обычные spawn требуют Send, а LocalSet снимает это требование, привязывая задачи к текущему потоку.

```rust
use std::rc::Rc;
use tokio::task;

#[tokio::main(flavor = "current_thread")]
async fn main() {
 let local = task::LocalSet::new();
 local.run_until(async {
 let r = Rc::new(1);
 task::spawn_local(async move { println!("{}", r); }).await.unwrap();
 }).await;
}
```

Здесь Rc, который не Send, спокойно живет в spawn_local.

#### 61. Что такое timeout и как его делать в tokio

Для ограничения времени операции используется tokio::time::timeout. Он оборачивает фьючу и возвращает Result, где Err это Elapsed. Если внутри был критичный ресурс, важно, что фьюча будет дропнута. См. cancel safety. Иначе можно оставить полузаписанный буфер или незакрытое соединение.

```rust
use tokio::time::{timeout, sleep, Duration};

#[tokio::main]
async fn main() {
 let r = timeout(Duration::from_millis(50), sleep(Duration::from_millis(100))).await;
 println!("{:?}", r);
}
```

Вывод Err(Elapsed). Удобно для защиты от подвисших внешних вызовов.

#### 62. Структурированная конкурентность, как ее делать в Rust

Идея структурированной конкурентности в том, что все дочерние задачи завершаются до того, как функция, которая их породила, вернет управление. Это упрощает рассуждение об ошибках и о времени жизни данных. В Rust на стандартной библиотеке такой паттерн строится через std::thread::scope. В async аналогов в std пока нет, но JoinSet, tokio_scoped, async-scoped или ручной select с graceful shutdown играют ту же роль.

```rust
use tokio::task::JoinSet;

async fn run() {
 let mut set = JoinSet::new();
 for i in 0..4 { set.spawn(async move { println!("{}", i); }); }
 while set.join_next().await.is_some() {}
}

#[tokio::main]
async fn main() { run().await; }
```

Когда run завершается, все задачи гарантированно отработали. Это и есть структурированный подход.

### Unsafe, FFI, низкий уровень

#### 63. Что разрешает unsafe и что он не отключает

Unsafe разрешает пять вещей. Разыменование сырого указателя, вызов unsafe функции или метода, доступ или изменение mutable static, реализацию unsafe трейта, обращение к union. Все остальные проверки компилятора остаются. Заимствование, типобезопасность, синтаксис, всё это работает как обычно. Unsafe не делает код быстрее само по себе и не отключает borrow checker.

```rust
fn main() {
 let mut x = 10;
 let p = &mut x as *mut i32;
 unsafe { *p += 1; }
 println!("{}", x);
}
```

Ключ в том, что ответственность за инварианты в этом блоке программист берет на себя.

#### 64. Что такое undefined behavior в Rust и какие самые частые причины UB

UB это поведение, для которого язык не дает никаких гарантий. Компилятор имеет право предполагать, что UB не возникает, и оптимизировать с учетом этого. В Rust типичные источники UB. Гонка данных через unsafe. Висячий указатель. Алиасинг ссылок несовместимым образом, например &mut и & одновременно через сырой указатель. Чтение неинициализированной памяти. Нарушение invariant Strict Aliasing для типизированных указателей. Передача невалидных значений примитивов, например bool со значением 2.

Правильная модель здесь такая. Любой unsafe должен иметь рядом комментарий с обоснованием, почему инварианты соблюдены.

#### 65. raw pointers vs references, что и когда использовать

Ссылки это безопасный примитив с гарантиями валидности и алиасинга. Сырые указатели *const T и *mut T этих гарантий не дают, не имеют лайфтайма и могут быть null. В прикладном коде сырые указатели почти не нужны. Появляются в FFI, в реализациях коллекций, в работе с памятью на низком уровне.

```rust
fn main() {
 let mut v = vec![1, 2, 3];
 let p: *mut i32 = v.as_mut_ptr();
 unsafe { *p.add(1) = 20; }
 println!("{:?}", v);
}
```

Индекс через сырой указатель не проверяется на выход за границы. Программист отвечает за это сам.

#### 66. MaybeUninit, зачем он нужен

MaybeUninit<T> это обертка, которая позволяет легально работать с неинициализированной памятью. Раньше для тех же целей использовали mem::uninitialized, но это давало UB для типов с непустыми инвариантами, например для bool или NonNull. MaybeUninit обходит это, потому что компилятор знает, что внутри может быть мусор, и не делает предположений.

```rust
use std::mem::MaybeUninit;

fn make_array() -> [u32; 4] {
 let mut arr: [MaybeUninit<u32>; 4] = unsafe { MaybeUninit::uninit().assume_init() };
 for (i, slot) in arr.iter_mut().enumerate() {
 slot.write(i as u32);
 }
 unsafe { std::mem::transmute(arr) }
}

fn main() { println!("{:?}", make_array()); }
```

Классический паттерн для построения массивов без лишних инициализаций.

#### 67. Что такое UnsafeCell и почему без него не сделать interior mutability

UnsafeCell это единственный легальный способ получить &mut T через &T. Все типы интерьорной мутабельности построены на нем. Сам по себе UnsafeCell не делает синхронизацию и не проверяет правила. Он только разрешает то, что иначе компилятор счел бы UB. Сверху уже строятся Cell, RefCell, Mutex, atomics. Поэтому если человек делает свой контейнер с интерьорной мутабельностью, начинать он будет с UnsafeCell.

#### 68. FFI с C, что нужно знать про репрезентацию типов

По умолчанию layout структуры в Rust не определен. Для совместимости с C ставят #[repr(C)]. Тогда поля идут в порядке объявления с padding по правилам C ABI. Аналогично, для enum, экспортируемых в C, используют #[repr(C)] или явный примитив #[repr(u32)]. Все типы, передаваемые через FFI, должны быть FFI safe. Например, String и Vec нельзя передавать напрямую, надо использовать сырой указатель и длину.

```rust
#[repr(C)]
struct Point { x: f64, y: f64 }

extern "C" {
 fn distance(a: Point, b: Point) -> f64;
}
```

#[repr(C)] обязательна, иначе layout может не совпасть.

#### 69. extern fn, calling conventions, panic через границу FFI

fn extern "C" задает соглашение вызова C. Без него используется внутренний Rust ABI, и интероп невозможен. Паника, вылетающая через границу FFI, это UB. Поэтому код, который вызывают из C, оборачивают в std::panic::catch_unwind. В Rust 2021 и новее unwinding через границу extern "C" по умолчанию приводит к abort, что само по себе уже спасает от UB, но обычно все равно явно ловят панику и возвращают код ошибки.

```rust
#[no_mangle]
pub extern "C" fn add(a: i32, b: i32) -> i32 {
 std::panic::catch_unwind(|| a + b).unwrap_or(-1)
}
```

Это базовый паттерн для библиотек, которые линкуются из C или Python.

#### 70. bindgen, cbindgen, cxx, чем они отличаются

Bindgen генерирует Rust обвязки из C заголовков. Cbindgen наоборот, по Rust коду делает C заголовки. Cxx это безопасный интероп с C++, с проверкой совместимости типов на этапе сборки. Если задача переписать часть C либы на Rust, обычно используют bindgen и cbindgen. Если интегрироваться с C++, cxx, потому что unsafe extern "C++" с виртуальными методами руками поддерживать невозможно.

#### 71. Что такое repr(transparent) и где он применяется

#[repr(transparent)] говорит, что структура с одним непрозрачным полем имеет такое же ABI и layout, как это поле. Используется в newtype паттернах, когда нужно передавать обертку через FFI или применять методы низкого уровня. Также обычно ставится на типы, реализующие интерьорную мутабельность.

```rust
#[repr(transparent)]
struct Wrapped(u32);

extern "C" { fn takes_u32(x: u32); }

fn main() {
 let w = Wrapped(7);
 unsafe { takes_u32(w.0); }
}
```

Wrapped по ABI неотличим от u32 и может безопасно использоваться в сигнатурах FFI.

#### 72. Что такое no_std и где он применяется

no_std это режим без стандартной библиотеки. Доступны только core и при желании alloc. Используется в эмбеддед, в ядрах ОС, в WASM рантаймах, в bootloaders. Особенности. Нет std::io, std::thread, std::fs. Нет println. Нет паники по умолчанию, нужен panic handler. Часто нет аллокатора, используют статические буферы и crate heapless.

```rust
#![no_std]
#![no_main]

use core::panic::PanicInfo;

#[panic_handler]
fn panic(_info: &PanicInfo) -> ! { loop {} }

#[no_mangle]
pub extern "C" fn _start() -> ! { loop {} }
```

Это минимальный скелет no_std программы.

#### 73. inline assembly в Rust, когда и как применяется

Макрос asm! позволяет писать ассемблер прямо внутри Rust. Полезен для интринзиков, которых нет в crate core_intrinsics, для управления регистрами в low level, для оптимизаций под конкретную архитектуру. Это очень узкая тема, в прикладе встречается редко. Использовать имеет смысл, когда измерения показывают, что компилятор не генерирует ожидаемые инструкции, и нет другого пути.

```rust
#[cfg(target_arch = "x86_64")]
fn rdtsc() -> u64 {
 let lo: u32; let hi: u32;
 unsafe { core::arch::asm!("rdtsc", out("eax") lo, out("edx") hi); }
 ((hi as u64) << 32) | lo as u64
}
```

Здесь читается счетчик циклов процессора.

#### 74. SIMD в Rust, основные подходы

Есть два уровня. Платформенно специфичные интринзики в core::arch и портабельный std::simd, который пока в nightly как experimental. Прикладно проще использовать crate wide или packed_simd, либо положиться на автовекторизацию LLVM. Чтобы автовекторизация сработала, цикл должен иметь регулярную форму, без зависимостей по данным между итерациями, и работать со срезом известного типа.

```rust
fn sum(a: &[f32]) -> f32 {
 let mut s = 0.0;
 for &x in a { s += x; }
 s
}
```

LLVM на release с -C target-cpu=native такой код почти всегда векторизует. Сначала имеет смысл проверить это, а уже потом писать руками.

#### 75. allocator API, что это и зачем оно

allocator API позволяет задать собственный аллокатор глобально через #[global_allocator] или локально для коллекций через Allocator. Глобальная замена часто используется для подключения jemalloc, mimalloc, snmalloc. Локальные аллокаторы полезны для арен, бамп аллокаторов и для эмбеддед, где память надо считать на байты.

```rust
use mimalloc::MiMalloc;

#[global_allocator]
static GLOBAL: MiMalloc = MiMalloc;

fn main() { let _ = vec![0u8; 1024]; }
```

Замена аллокатора нередко дает 5 15 процентов общего ускорения на нагруженных сервисах без правки бизнес кода.

#### 76. mem::transmute, его опасности и альтернативы

transmute побитово реинтерпретирует значение одного типа как другой. Это одна из самых опасных функций в языке. Она безопасна, только если оба типа имеют одинаковый layout и значение остается валидным в новом типе. Например, перетранслировать u32 в f32 можно, потому что у обоих 4 байта. Перетранслировать u8 в bool нельзя, потому что bool не любое значение валидно. Безопасные альтернативы. from_bits для floats, методы to_ne_bytes from_ne_bytes для разбора, bytemuck и zerocopy для proven safe конверсий.

#### 77. Что такое volatile операции и где они нужны

volatile это операции чтения и записи, которые компилятор не имеет права оптимизировать или переупорядочивать. В Rust это std::ptr::read_volatile и write_volatile. Нужны для работы с memory mapped регистрами устройств, где каждое чтение и каждая запись имеет побочный эффект на железо. В обычном многопоточном коде volatile не заменяет atomics. У них разные гарантии. Для синхронизации между потоками используется atomic, для общения с железом volatile.

#### 78. Особенности написания собственного unsafe API

Главный принцип. Если функция unsafe, она должна явно документировать свои инварианты, что обязан гарантировать вызывающий. Если функция safe, она внутри может содержать unsafe, но снаружи должна быть невозможна никакая комбинация валидных аргументов и состояний, которая приводит к UB. Это называется sound API. Любое отступление это потенциальный security баг. Поэтому в библиотеках с большим unsafe принято писать раздел Safety в doc комментарии и покрывать код Miri.

```rust
/// # Safety
/// ptr должен указывать на валидный u8 буфер длиной не меньше len.
pub unsafe fn read_buf(ptr: *const u8, len: usize) -> Vec<u8> {
 std::slice::from_raw_parts(ptr, len).to_vec()
}
```

Документация это не косметика. Это контракт, без которого использовать unsafe правильно нельзя.

### Производительность

#### 79. Как профилировать Rust код

Для CPU профайла стандартный инструмент это perf на Linux плюс flamegraph. Под капотом это сэмплирующий профайлер, который собирает стеки и строит дерево. Дополнительно используют cargo-flamegraph, который оборачивает запуск и сразу генерит svg. Для аллокаций есть heaptrack, dhat и crate dhat. Для async кода у tokio есть console подсистема через tokio-console, она показывает зависшие таски и долгоудерживаемые локи. Замеры микробенчмарков делают через criterion.

Практический подход. Сначала измерить, найти горячее место, потом править. Не наоборот. Угадывание узких мест в Rust почти всегда уходит мимо, потому что компилятор очень многое инлайнит.

#### 80. Inlining, как им управлять и когда это полезно

Компилятор сам решает, что инлайнить, опираясь на размер функции, число вызовов, profile guided оптимизации. Атрибуты #[inline], #[inline(always)], #[inline(never)] дают подсказки. #[inline] нужен в первую очередь для функций в библиотеках, потому что без него вызов из другого crate не сможет быть заинлайнен. always стоит ставить редко, обычно для тонких оберток над интринзиками. Никогда полезен для холодного кода типа error reporting, чтобы он не раздувал горячий путь.

```rust
#[inline]
pub fn fast_add(a: u32, b: u32) -> u32 { a.wrapping_add(b) }
```

Для библиотечного crate такой атрибут практически обязателен на простых функциях.

#### 81. Allocations, как их избегать в горячем коде

Каждая аллокация это поход в аллокатор, потенциально с локом. На горячем пути аллокации обычно главная стоимость. Способы их избегать. Использовать буферы, выделенные один раз и переиспользуемые. clear vs new. Применять методы collect_into и extend_from_slice вместо collect нового Vec. Использовать smallvec для коллекций, где обычно мало элементов. Использовать String::with_capacity и Vec::with_capacity, чтобы избежать ресайзов. По возможности возвращать &str или Cow вместо String.

```rust
fn build_lines(out: &mut String, n: u32) {
 out.clear();
 out.reserve(n as usize * 4);
 for i in 0..n {
 use std::fmt::Write;
 let _ = write!(out, "{}\n", i);
 }
}
```

out приходит снаружи и переиспользуется. Никакой новой String на каждом вызове.

#### 82. Vec и его модель роста, capacity

Vec хранит указатель, длину и емкость. При переполнении вызывается реаллокация, которая копирует данные на новое место. Стратегия роста обычно удвоение, но конкретная реализация может отличаться. Если число элементов известно заранее, with_capacity дает только одну аллокацию. shrink_to_fit имеет смысл, если вектор больше не будет расти. Для часто переиспользуемых буферов лучше держать емкость и периодически делать clear.

```rust
fn main() {
 let mut v = Vec::with_capacity(1000);
 for i in 0..1000 { v.push(i); }
 println!("{} {}", v.len(), v.capacity());
}
```

Должен быть один промах в аллокаторе на тысячу push, а не десять.

#### 83. String, str и работа с UTF-8

String это владеющий буфер UTF-8. &str это срез валидного UTF-8. Индексация по байтам разрешена через [..], но только по границам символов. По произвольному индексу будет паника. Для обработки символов используют методы chars, char_indices. Не любая операция в char это операция в UTF-8 байтах. Длина строки в символах считается через s.chars().count, а не через len. Это дорого, потому что O от количества байт.

```rust
fn main() {
 let s = "привет";
 println!("{} {}", s.len(), s.chars().count()); // 12 6
}
```

Если надо много раз спрашивать длину в символах, лучше один раз посчитать и кэшировать.

#### 84. HashMap и hash DOS, что такое SipHash и зачем нужны другие хешеры

Стандартный HashMap использует SipHash 1 3 с рандомизированным ключом. Это защищает от hash flooding атак, но медленнее на коротких ключах, чем нелинейные альтернативы. Для внутренних, не атакоопасных карт часто берут ahash или fxhash. Они в 2 3 раза быстрее, но не криптостойкие. На API границе с пользовательскими данными SipHash оставляют.

```rust
use std::collections::HashMap;
use ahash::RandomState;

fn main() {
 let mut m: HashMap<u64, u64, RandomState> = HashMap::default();
 for i in 0..100 { m.insert(i, i * i); }
 println!("{}", m[&5]);
}
```

Выбор хешера это всегда tradeoff между безопасностью и скоростью.

#### 85. Что такое branch prediction и как мы можем помочь компилятору

Процессор предсказывает ветвления. Промах стоит десятки циклов. Помогать можно. Через #[cold] на функциях обработки редких случаев. Через likely и unlikely интринзики в std::intrinsics или через crate likely_stable. Через реструктуризацию кода, чтобы горячий путь был прямым, без вложенных match. На уровне выражений match со многими вариантами компилируется в jump table, что обычно лучше длинной цепочки if else.

```rust
fn parse(b: &[u8]) -> Option<u32> {
 if b.is_empty() { return None; }
 let mut acc = 0u32;
 for &c in b {
 if !c.is_ascii_digit() { return None; }
 acc = acc.wrapping_mul(10).wrapping_add((c - b'0') as u32);
 }
 Some(acc)
}
```

Горячая ветка для цифр идет первой и без вложений. Это тот случай, когда читаемость и скорость совпадают.

#### 86. Cache friendly код в Rust, как структурировать данные

Локальность данных решает. Vec<T> с маленькими T работает быстрее, чем Vec<Box<T>>, потому что доступ последовательный, без промахов кэша. SoA (struct of arrays) часто быстрее AoS (array of structs), если код одновременно работает только с подмножеством полей. Это типичный паттерн для рантаймов игр и для аналитики. Сами по себе типы вроде SmallVec и tinyvec выигрывают именно на этом, потому что прячут небольшие данные внутри стека.

```rust
struct WorldAoS { items: Vec<(u32, f32, f32)> }
struct WorldSoA { ids: Vec<u32>, x: Vec<f32>, y: Vec<f32> }
```

Если алгоритм гоняет по x и y и не трогает id, SoA попадает в кэш плотнее.

#### 87. Что такое monomorphization cost и как с ней жить

Каждый дженерик инстансциируется под конкретный тип. Это раздувает бинарник и время компиляции. На больших проектах это становится заметно. Лекарства. Делить функции на тонкую generic обертку и толстую non generic реализацию, которая принимает &dyn или &str вместо impl Trait. Не делать дженерики там, где достаточно &str или &[u8]. Использовать impl Trait внутри функций, а не на API границе, если не нужна гибкость.

```rust
fn log_inner(s: &str) { println!("{}", s); }
pub fn log<T: AsRef<str>>(s: T) { log_inner(s.as_ref()); }
```

Генерик мономорфизируется в тонкую функцию, которая просто зовет общую log_inner. Бинарник растет минимально.

#### 88. PGO и LTO, что это и стоит ли включать

LTO это link time optimization, она позволяет инлайнить и оптимизировать через границы крейтов. Включается в Cargo.toml профиле release. Дает обычно 5 15 процентов скорости и заметно более долгий линк. Thin LTO быстрее, fat LTO медленнее, но иногда чуть лучше. PGO это profile guided optimization, компилятор использует данные о реальных вызовах для выбора инлайнов и реструктуризации кода. Дает еще 5 20 процентов на хорошо профилируемой рабочей нагрузке. Для серверного кода почти всегда оправдано.

```toml
[profile.release]
lto = "fat"
codegen-units = 1
```

codegen-units = 1 ограничивает параллелизм компиляции, но дает компилятору больше контекста для оптимизаций.

#### 89. Profile guided optimization и benchmarks с criterion

Criterion это de facto стандарт микробенчмарков в Rust. Запускает функцию много раз, выкидывает выбросы, считает доверительные интервалы. Главное при бенчинге это правильно сравнивать релизный билд с тем же набором фич. Microbench легко обмануть себя, если не позаботиться о black_box, который мешает компилятору соптимизировать вычисление до константы.

```rust
use criterion::{black_box, criterion_group, criterion_main, Criterion};

fn sum_to(n: u64) -> u64 { (1..=n).sum() }

fn bench(c: &mut Criterion) {
 c.bench_function("sum_to_1000", |b| b.iter(|| sum_to(black_box(1000))));
}

criterion_group!(benches, bench);
criterion_main!(benches);
```

bench запускается через cargo bench. Результаты сохраняются и сравниваются между прогонами.

### Макросы и метапрограммирование

#### 90. Декларативные макросы macro_rules, базовые принципы

Декларативный макрос задается через macro_rules. У него есть набор правил matcher to transcriber, где matcher описывает синтаксис, а transcriber генерирует код. Используются фрагменты expr, ident, ty, tt и другие. Это безопасный способ генерировать код, который виден в синтаксическом дереве до тайпчека. Подходит для DSL, для упрощения повторяющегося кода, для конструкторов коллекций.

```rust
macro_rules! hashmap {
 ($($k:expr => $v:expr),* $(,)?) => {{
 let mut m = std::collections::HashMap::new();
 $( m.insert($k, $v); )*
 m
 }};
}

fn main() {
 let m = hashmap! { "a" => 1, "b" => 2 };
 println!("{:?}", m);
}
```

Это типовой паттерн. Если в проекте появилось много повторяющихся инициализаций, такой макрос обычно оправдан.

#### 91. Гигиена макросов, что это и какие у нее границы

Гигиена это свойство макроса не путать свои идентификаторы с пользовательскими. Декларативные макросы Rust в основном гигиеничны для локальных имен. Это значит, что let x = 5 внутри макроса не перекрывает x в вызывающем контексте. Полной гигиены для всех видов имен пока нет, особенно для типов и трейтов. Поэтому в макросах безопаснее писать $crate::path::to::Item вместо просто Item.

```rust
macro_rules! once {
 () => { let x = 1; let _ = x; };
}

fn main() {
 let x = 10;
 once!();
 println!("{}", x); // 10, не перекрыто
}
```

Эта гигиена убирает целый класс багов, которые были типичны для макросов в C.

#### 92. Процедурные макросы, три вида

Есть три вида proc macros. Function like, которые вызываются как make_thing!. Derive макросы, которые вешаются на структуру через #[derive(Foo)]. Attribute макросы, которые модифицируют элемент через #[my_attr]. Под капотом все три получают TokenStream и возвращают TokenStream. Для разбора используют syn, для генерации quote, для отображения ошибок proc-macro-error.

```rust
// Cargo.toml: [lib] proc-macro = true
// use proc_macro::TokenStream;
// use quote::quote;
// #[proc_macro_derive(Hello)]
// pub fn hello(input: TokenStream) -> TokenStream {
// let ast: syn::DeriveInput = syn::parse(input).unwrap();
// let name = &ast.ident;
// quote! { impl #name { fn hello() { println!("hello from {}", stringify!(#name)); } } }.into()
// }
```

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

#### 93. Build script build.rs, типичные применения

build.rs запускается перед сборкой crate. Используется для генерации кода, для подключения C библиотек через cc, для проверки фич окружения, для генерации констант на основе git. Общается с cargo через печать строк cargo:rerun-if-changed=, cargo:rustc-cfg=, cargo:warning=. В большом проекте build.rs часто становится точкой, где собирают protobuf, capnproto, flatbuffers схемы и кладут результаты в OUT_DIR.

```rust
// build.rs
fn main() {
 println!("cargo:rerun-if-changed=schema.proto");
 println!("cargo:rustc-env=BUILD_VERSION=1.0.0");
}
```

Generated файлы потом подключают через include!(concat!(env!("OUT_DIR"), "/schema.rs")).

#### 94. Что такое const fn и какие у нее ограничения

const fn это функция, которая может быть вычислена в compile time. Применяется для создания констант, для размеров массивов, для логики, которую хочется проверять статически. Ограничения медленно ослабляются. Раньше нельзя было if внутри const fn, теперь можно. Многие методы стандартной библиотеки уже const. Аллокации в const fn пока ограничены, циклы разрешены.

```rust
const fn square(n: u32) -> u32 { n * n }

const N: u32 = square(7);
static ARR: [u8; square(2) as usize] = [0; 4];

fn main() { println!("{} {}", N, ARR.len()); }
```

const fn полезен в библиотечном коде. Конфигурация и константы становятся вычислимыми, и тип системе доступно больше информации.

#### 95. Что такое typestate и как он реализуется в Rust

Typestate это паттерн, при котором состояние объекта закодировано в его типе. Невозможные переходы не компилируются. Реализуется через generic параметры, fantom типы и trait bounds. Очень часто встречается в API сетевых протоколов и парсеров. Builder тоже это разновидность typestate, когда обязательные поля проверяются типом возвращаемого значения.

```rust
struct Open; struct Closed;
struct Socket<S> { _s: std::marker::PhantomData<S> }

impl Socket<Closed> { fn open(self) -> Socket<Open> { Socket { _s: std::marker::PhantomData } } }
impl Socket<Open> { fn close(self) -> Socket<Closed> { Socket { _s: std::marker::PhantomData } } }

fn main() {
 let s = Socket::<Closed> { _s: std::marker::PhantomData };
 let o = s.open();
 // o.open(); // ошибка, у Open нет open
 let _ = o.close();
}
```

Компилятор не даст вызвать open на уже открытом сокете. Это бесплатный рантайм инвариант.

### Архитектура и дизайн API

#### 96. Builder pattern в Rust, как делать правильно

Builder используется, когда у структуры много полей, часть из которых опциональна. В Rust типовая реализация это отдельный билдер тип с методами с цепочечным возвратом self или &mut self. Для обязательных полей часто используется typestate, тогда build не скомпилируется без них. Альтернативно, build возвращает Result с описанием отсутствующего поля. Первый вариант жестче, второй гибче.

```rust
struct Client { url: String, timeout_ms: u32 }

struct ClientBuilder { url: Option<String>, timeout_ms: u32 }

impl ClientBuilder {
 fn new() -> Self { Self { url: None, timeout_ms: 1000 } }
 fn url(mut self, u: impl Into<String>) -> Self { self.url = Some(u.into()); self }
 fn timeout_ms(mut self, t: u32) -> Self { self.timeout_ms = t; self }
 fn build(self) -> Result<Client, &'static str> {
 Ok(Client { url: self.url.ok_or("url required")?, timeout_ms: self.timeout_ms })
 }
}

fn main() {
 let _c = ClientBuilder::new().url("http://x").timeout_ms(500).build().unwrap();
}
```

Для сложного API правильный builder сильно повышает читаемость вызовов.

#### 97. Error handling, anyhow и thiserror, когда что

thiserror используется для библиотечных ошибок. Дает derive для enum, который реализует std::error::Error с источниками и сообщениями. anyhow используется в приложениях, где нужно собирать ошибки из разных источников в один опрозрачный тип с контекстом. Правило большого пальца. Внутри библиотеки thiserror и осмысленные enum. На уровне main и интеграционных слоев anyhow и контекст.

```rust
use thiserror::Error;

#[derive(Error, Debug)]
enum StoreError {
 #[error("io: {0}")]
 Io(#[from] std::io::Error),
 #[error("missing key {0}")]
 Missing(String),
}

fn load(path: &str) -> Result<String, StoreError> {
 Ok(std::fs::read_to_string(path)?)
}
```

Вызывающий код получает четкий enum и может матчить на конкретные варианты, а не разбирать строку.

#### 98. Дизайн API на трейтах, что отдавать наружу

Хороший публичный API скрывает реализацию и фиксирует контракт. На практике это значит. Возвращать impl Trait вместо конкретных типов, чтобы не закладываться на детали. Принимать impl IntoIterator или impl AsRef, чтобы не заставлять пользователя конвертировать. Не светить дженерики, которые нужны только внутри. Делать новые методы по необходимости, не превращать трейты в свалку. Чем меньше у трейта методов, тем легче его реализовать сторонним типам.

```rust
pub trait KV {
 fn get(&self, key: &str) -> Option<String>;
 fn put(&mut self, key: &str, value: &str);
}
```

Комментарий. Минимальный набор методов, никаких лишних дженериков, легко мокать в тестах.

#### 99. Versioning, semver и breaking changes в Rust

Rust crates следуют semver. Patch это совместимые исправления, minor добавление API без поломок, major breaking changes. Что считается breaking. Удаление публичного элемента, изменение сигнатуры, переименование, новые обязательные методы в pub трейте, новые обязательные generic параметры. Что не breaking. Новые public функции, новые варианты в #[non_exhaustive] enum, добавление #[must_use]. Чтобы спокойно менять enum в будущем, его помечают non_exhaustive еще в первой версии.

```rust
#[non_exhaustive]
pub enum Event { Connected, Disconnected }
```

Теперь добавление третьего варианта в minor релизе не сломает пользователей.

#### 100. Безопасный multi crate workspace, как организовать большой проект

Для проекта, который перерос один crate, типичная структура это cargo workspace с несколькими членами. Например, core содержит чистую логику без IO. db содержит работу с хранилищем. http содержит транспорт. bin собирается из них и не содержит логики. Это дает понятные границы зависимостей, ускоряет инкрементальную сборку и упрощает тестирование. Внутри workspace полезны общие dependencies в workspace.dependencies, чтобы версии не разъезжались.

```toml
[workspace]
members = ["core", "db", "http", "bin"]

[workspace.dependencies]
serde = { version = "1", features = ["derive"] }
tokio = { version = "1", features = ["full"] }
```

Из практики. Чем чище разделены крейты по обязанностям, тем проще менять одно, не задевая другое. Это главный практический выигрыш Rust workspace.

## Продвинутые вопросы уровня staff и expert

Раздел для тех, кто уже свободно ориентируется в первых ста вопросах. Здесь темы, которые встречаются на собеседованиях в системные команды, на позиции staff, и при разработке библиотек на грани soundness.

### Тонкости системы типов

#### A1. Что такое GAT (Generic Associated Types) и какую проблему они решают

GAT - ассоциированные типы, которые сами параметризованы лайфтаймами или типами. До их стабилизации (Rust 1.65) невозможно было выразить трейт типа `LendingIterator`, у которого `next` возвращает значение, заимствованное у самого итератора.

```rust
trait LendingIterator {
 type Item<'a> where Self: 'a;
 fn next(&mut self) -> Option<Self::Item<'_>>;
}
```

Обычный `Iterator` не справится: `type Item` без параметра не может зависеть от лайфтайма `&mut self`. Это блокирует написание итераторов по chunked slices с отдачей `&mut [T]` без unsafe, итераторов по строкам файла с переиспользованием буфера, потоковых парсеров.

Подводные камни. GAT часто требуют сложных where-clauses (`where Self: 'a`), и тип, опирающийся на GAT, плохо превращается в `dyn Trait` - object safety нарушается, если GAT использует Self в позициях, которые невозможно стереть. Решение: либо отказаться от `dyn`, либо предоставить вспомогательный нелендящий вариант трейта.

#### A2. HRTB и for<'a>: где встречается и зачем

Higher-Ranked Trait Bound - bound вида `for<'a> F: Fn(&'a T) -> &'a U`. Означает «`F` реализует `Fn` для любого лайфтайма `'a`», а не для какого-то конкретного.

Чаще всего HRTB всплывает с замыканиями, принимающими ссылки.

```rust
fn apply<F>(f: F) where F: for<'a> Fn(&'a str) -> &'a str {
 let s = String::from("hi");
 let r = f(&s);
 println!("{r}");
}
```

Без `for<'a>` компилятор попытался бы зафиксировать конкретный `'a` на сайте объявления функции, и замыкание не подошло бы для строки, созданной внутри.

HRTB обычно выводится автоматически (elision), явно его пишут редко: при сложных трейтах с несколькими ссылками, при работе со сложными комбинаторами, при определении трейтов вроде `Fn`.

Ограничения. HRTB пока работает только с лайфтаймами; для типов аналога нет (это обсуждается под именем generic HRTB). Слишком сложные HRTB-комбинации компилятор может не свести, и приходится переписывать сигнатуру.

#### A3. Variance: ковариантность, контравариантность, инвариантность

Variance описывает, как лайфтайм или тип-параметр распространяется через ссылку или конструктор типа.

`&'a T` ковариантен по `'a` и по `T`. Если `'long: 'short`, то `&'long T` можно использовать там, где ожидается `&'short T`. Это безопасно: длинная жизнь подходит для короткого контекста.

`&'a mut T` ковариантен по `'a`, но инвариантен по `T`. Иначе можно было бы записать `&'a mut Cat` через `&'a mut Animal` и сломать инварианты типа.

`fn(T) -> U` контравариантен по `T` и ковариантен по `U`. Функция, принимающая `Animal`, подойдёт там, где ждут функцию, принимающую `Cat` - но не наоборот.

`PhantomData` контролирует variance структуры. `PhantomData<&'a T>` делает ковариантным по `'a` и `T`. `PhantomData<*mut T>` делает инвариантным. `PhantomData<fn(T)>` - контравариантным по `T`.

Почему это важно. При написании unsafe-обёрток над сырыми указателями вы сами выбираете variance, и неправильный выбор открывает soundness-дыру.

#### A4. Лайфтайм subtyping и где это всплывает на практике

`'a: 'b` (читается «'a outlives 'b») означает, что `'a` живёт не короче `'b`. На основе этого строятся проверки assignability ссылок.

Практический пример: возврат позаимствованного значения из обобщённой функции с несколькими лайфтаймами.

```rust
fn pick<'a, 'b: 'a>(x: &'a str, y: &'b str) -> &'a str { x }
```

Bound `'b: 'a` нужен, если результат логически смешивает входы. Без него компилятор не позволит вернуть `y`.

Ещё встречается: В трейтах с GAT часто пишут `where Self: 'a`, что эквивалентно «`'a` не дольше `Self`». В асинхронных футурах HRTB и subtyping переплетаются: компилятор подбирает регион так, чтобы все ограничения сходились, и иногда сообщения об ошибках становятся загадочными.

#### A5. Variance и soundness pitfall с `*mut T` против `*const T`

Сырой `*mut T` инвариантен по `T`, `*const T` ковариантен. Если вы пишете кастомный smart pointer на `*mut T`, но хотите ковариантности (это семантически безопасно для read-only), нужно либо использовать `NonNull<T>` (ковариантен), либо явно фиксировать variance через `PhantomData`.

Где это ломается: `struct Erased { ptr: *mut () }` нельзя использовать с trait object-ами через приведение в `*mut dyn Trait` без понимания, что инвариантность по `()` ничего не значит для самого `dyn`. Авторы `Arc` и `Rc` тщательно подбирают `PhantomData` именно для этих причин.

### Async, Pin, Unpin

#### A6. Что такое Pin и зачем он нужен async fn

`Pin` - обёртка над smart pointer, гарантирующая, что pinned значение не будет перемещено в памяти до своего дропа (или до `Unpin`-выхода). Это критично для self-referential типов: если структура держит указатель на собственное поле, move сделает указатель висящим.

Async-функции генерируют такие структуры автоматически. `async fn foo() -> u32` компилируется в анонимную структуру-стейтмашину, поля которой могут содержать ссылки на другие поля той же структуры (через `.await` на ссылку из `let`). Future в Rust позиционирован как `Future` именно потому, что `poll(self: Pin<&mut Self>)`.

`Unpin` - auto trait, говорящий «этот тип безопасно перемещать, даже когда он pinned». Большинство пользовательских типов `Unpin`. Стейтмашины `async fn` обычно не `Unpin` (если только не специально), потому что компилятор не доказывает отсутствие self-references.

Внутри Pin никакой магии. На уровне памяти `Pin<&mut T>` - обычная ссылка, контракт держится только на дисциплине: API не выдаёт `&mut T` из `Pin<&mut T>` без `unsafe`, кроме как для `T: Unpin`.

#### A7. Структурный pin projection и pin-project

Есть `Pin<&mut Outer>`, хочется получить `Pin<&mut Inner>` для конкретного поля. Это можно сделать только если автор `Outer` принял на себя обязательство: либо все pinned-проекции остаются pinned, либо ни одна. Безопасный код этого не сделает.

Крейт `pin-project` (и `pin-project-lite`) генерирует корректный код проекций. Помечаете поле `#[pin]` - оно проектируется как `Pin<&mut Field>`. Без `#[pin]` - как обычный `&mut Field`. Дроп через `PinnedDrop` обрабатывается отдельно.

Реальная польза - реализация комбинаторов вроде `Select`, `Join`, `Timeout` поверх существующих futures без unsafe.

#### A8. Cancellation safety в async и где это ломается

Future в Rust «отменяется» дропом. Если задача в `select!` потеряла гонку, её future дропается, и любой прогресс теряется. Cancellation-safe future гарантирует, что после дропа состояние внешнего мира согласовано.

Классическая ловушка - `AsyncRead::read` на TCP-сокете. `tokio::io::AsyncReadExt::read` cancel-safe: если future дропнули до завершения, прочитанные байты потеряны, но сам сокет цел. А вот `read_exact` не cancel-safe: при дропе посередине часть байт уже потреблена из ядра, и следующий вызов получит «продолжение» с непредсказуемой точки.

Сюда же относятся mutex futures из `parking_lot::FairMutex::lock_async` - некоторые реализации после отмены могут оставить очередь в неконсистентном состоянии. `tokio::sync::Mutex::lock` cancel-safe.

Практическое правило. В `select!` использовать только cancel-safe futures. Если есть сомнения, оборачивать в `tokio::spawn` (отдельная задача не отменяется снаружи) или в `tokio::pin!` + ручной `poll`.

#### A9. Что компилятор делает с async fn внутри: state machine

`async fn` превращается в анонимную enum-подобную структуру с одним вариантом на каждое await-точку плюс «начало» и «конец». Поля структуры - локальные переменные, переживающие `await`. Структура реализует `Future` с `poll`, который читает текущее состояние и продолжает выполнение.

Размер. Сумма «толстейших» путей по awaitам. Локальные переменные с пересекающимися лайфтаймами не объединяются, поэтому большие async fn раздувают future. `Box::pin` на «толстый» future полезен, чтобы не таскать его по стеку рекурсивно.

Send/Sync. Если хоть одно поле future не `Send`, future не `Send`. Самая частая причина «future is not Send» - удержание `MutexGuard` или `RefCell::borrow` через await. Решение: либо локализовать guard в блоке без awaitов (`{ let g = ...; }` до `.await`), либо использовать `tokio::sync::Mutex`, чьи guard-ы `Send`.

#### A10. `async fn` в трейтах: RPITIT, async-trait, dyn-compatibility

С Rust 2024 `async fn` в трейтах стабилизирован через RPITIT (return position impl trait in traits). Раньше использовали крейт `async-trait`, который оборачивает каждый метод в `Pin<Box<dyn Future>>` - удобно, но добавляет аллокацию на каждый вызов.

```rust
trait Storage {
 async fn put(&self, k: String, v: Vec<u8>) -> Result<(), Error>;
}
```

Object safety. `dyn Storage` для async trait через RPITIT работает с ограничениями: размер возвращаемого future статически неизвестен, его нужно либо боксировать (`async-trait`), либо использовать `#[trait_variant]` для генерации обеих версий, либо отказываться от `dyn`.

Send-bound. Если `dyn Storage` нужен в Send-контексте, есть макросы вроде `#[trait_variant::make(Send)]`, которые добавляют `+ Send` к возвращаемому future каждого метода. Без этого `dyn` не Send.

### Память, layout, unsafe-инварианты

#### A11. Stacked Borrows и Tree Borrows: что проверяет Miri

Stacked Borrows - формальная модель алиасинга в Rust, описывающая, какие комбинации ссылок и сырых указателей не вызывают UB. Miri (интерпретатор MIR) проверяет код по этой модели и ловит ошибки, которые компилятор пропустит.

Каждой ссылке присваивается «тег». Все ссылки на один объект образуют стек тегов. Создание новой ссылки кладёт тег на верх стека. Использование старой ссылки требует, чтобы её тег был ещё в стеке; если поверх него легла `&mut`, старый тег «выкинут», и использование - UB.

Tree Borrows - новая модель, более либеральная: вместо стека дерево. Принимает паттерны, которые Stacked Borrows отвергает (например, two-phase borrows в некоторых сценариях), сохраняя ключевые гарантии.

Практически. Если `cargo +nightly miri test` ругается на ваш unsafe-код, это серьёзный сигнал. Даже если на текущем компиляторе всё «работает», следующий релиз LLVM может оптимизировать вашу программу в неверный код.

#### A12. Memory ordering на atomic: что значат Relaxed/Acquire/Release/SeqCst

Atomic operations задают ordering для модели памяти C++20 (Rust использует ту же).

`Relaxed` гарантирует только атомарность самой операции. Никакой синхронизации с другими переменными. Подходит для счётчиков, где порядок относительно других данных не важен (например, инкремент strong count в `Arc`).

`Release` (на store) и `Acquire` (на load) образуют пару happens-before. Все записи перед `Release` видны потоку, выполнившему `Acquire` на той же переменной после неё. Это стандарт для lock-free структур.

`AcqRel` - комбинация для read-modify-write операций (`fetch_add`, `compare_exchange`).

`SeqCst` - дополнительно гарантирует единый глобальный порядок всех SeqCst-операций. Самый дорогой по производительности, но даёт интуитивную модель «как будто всё последовательно».

Грабли: `Relaxed` декремент strong count в `Arc` корректен только потому, что финальный декремент использует `Acquire`. Это тонкий паттерн, бездумное копирование в свои структуры даст data race.

#### A13. Loom: как искать гонки в lock-free коде

`loom` - библиотека для model checking конкурентного кода. Запускает ваш тест миллион раз, перебирая все возможные перестановки атомиков и блокировок по разрешённым моделью памяти. Если есть хотя бы один interleaving, дающий некорректный результат, loom его найдёт.

Как пользоваться. Помечаете тесты `#[cfg(loom)]`, заменяете `std::sync::Mutex` на `loom::sync::Mutex`, `std::sync::atomic::AtomicUsize` на `loom::sync::atomic::AtomicUsize`. Запускаете `RUSTFLAGS="--cfg loom" cargo test`.

Ограничения. Loom медленный (поэтому тесты должны быть маленькие, типично 2-3 потока). Не обнаруживает багов, требующих специфичной аппаратной модели (ARM/POWER weak memory) - проверяется только модель C++20. Не подменяет Miri: loom про конкурентность, Miri про aliasing UB.

#### A14. Niche optimization: где компилятор кладёт тег в «дыру»

Niche - значение, которое тип не может принимать, и компилятор использует его для кодирования дискриминанта. Самый известный пример - `Option<NonNull<T>>` или `Option<&T>` имеют размер указателя: `None` это нулевой бит.

Дополнительные niche приходят от `NonZeroU32`, `NonZeroUsize` (значение `0` исключено), от `bool` (только `0` и `1`, остальные значения - niche), от `char` (валидные кодпоинты), от `enum E { A, B }` (только два дискриминанта используются, остальные значения тега - niche).

`#[repr(transparent)]` сохраняет niche обёрнутого типа. `#[repr(C)]` обычно теряет.

Реальный эффект. `Vec<Option<&T>>` весит как `Vec<&T>`. `HashMap` с ключом `Option<NonZeroU32>` не тратит дополнительный байт. `Result<u32, NonZeroI32>` - неочевидно, но тоже работает через niche, если ошибка не нулевая.

#### A15. Custom allocator и GlobalAlloc trait

`#[global_allocator]` позволяет заменить аллокатор для всей программы. Тип должен реализовать `GlobalAlloc`: `alloc`, `dealloc`, `alloc_zeroed`, `realloc`. Это unsafe-трейт; нарушение контрактов (например, возврат пересекающихся аллокаций) - UB.

```rust
use std::alloc::{GlobalAlloc, Layout};
struct MyAlloc;
unsafe impl GlobalAlloc for MyAlloc {
 unsafe fn alloc(&self, l: Layout) -> *mut u8 { /* */ unimplemented!() }
 unsafe fn dealloc(&self, p: *mut u8, l: Layout) { /* */ }
}

#[global_allocator]
static A: MyAlloc = MyAlloc;
```

Аллокатор-на-тип (только для одной коллекции) делается через `Allocator` trait и `Box::new_in`, `Vec::new_in`. Стабильно: `Allocator` ещё nightly, на стабильном пользуются крейтами вроде `allocator-api2`.

Где это нужно: real-time системы (без вызова `mmap` на горячем пути). Подсчёт аллокаций для трекинга в тестах. Arena-аллокаторы для парсеров, где всё умирает разом. jemalloc/mimalloc как замена системного для лучшей производительности в многопоточных сервисах.

### Soundness и API design

#### A16. Drop check (dropck) и почему он иногда отвергает корректный код

Dropck - подсистема borrow checker, проверяющая, что в момент дропа значения все ссылки, которые оно содержит, ещё валидны. Это важно для типов с кастомным `Drop`, который потенциально читает свои поля.

Где это ломается:

```rust
struct Holder<'a, T: 'a> { item: &'a T }
impl<'a, T> Drop for Holder<'a, T> {
 fn drop(&mut self) { /* возможно читает item */ }
}
```

Здесь `Drop::drop` берёт `&mut self`, у которого есть `&'a T` внутри. Dropck требует, чтобы `T` был жив в момент дропа `Holder`. Это иногда отвергает программы, которые на первый взгляд корректны.

Атрибут `#[may_dangle]` (nightly + `dropck_eyepatch`) позволяет автору `Drop` объявить «я не трогаю это поле в drop», чтобы dropck стал мягче. Так делает `Vec<T>` и `Box<T>`.

#### A17. Sealed trait pattern и контроль расширяемости API

Sealed trait - паттерн, при котором публичный трейт нельзя реализовать снаружи крейта, при этом он остаётся видимым и используемым в bound-ах.

```rust
mod private { pub trait Sealed {} }

pub trait MyTrait: private::Sealed { fn foo(&self); }

impl private::Sealed for u32 {}
impl MyTrait for u32 { fn foo(&self) {} }
```

Зачем. Гарантия для автора крейта, что добавление методов в `MyTrait` не сломает чужой код (поскольку реализаций «снаружи» нет). Полезно для трейтов, отражающих закрытое множество типов (`Number` для встроенных числовых).

Альтернатива - `#[non_exhaustive]` для enum-ов и структур, чтобы запретить exhaustive match и конструирование снаружи.

#### A18. Type-state pattern: API, который нельзя использовать неправильно

Type-state кодирует состояние объекта в типе. Методы, валидные только в определённом состоянии, доступны только в типе этого состояния.

```rust
struct Request<S> { url: String, _s: std::marker::PhantomData<S> }
struct Draft; struct Sent;

impl Request<Draft> {
 fn new(url: String) -> Self { Self { url, _s: std::marker::PhantomData } }
 fn send(self) -> Request<Sent> { Request { url: self.url, _s: std::marker::PhantomData } }
}
impl Request<Sent> {
 fn response(&self) -> String { String::from("ok") }
}
```

Преимущество: компилятор гарантирует, что `response` не вызовут на черновике. Цена: больше параметров в типе, иногда нужны helper-trait-ы (`impl<S: Stateful> Request<S>` для общих методов).

Где применяется. Стейт-машины протоколов (TCP-handshake, OAuth-флоу), билдеры с обязательными полями, ресурсы с фазами инициализации.

#### A19. Soundness pitfall: `mem::transmute` и трейт-объекты

`mem::transmute` побитово переинтерпретирует значение. Для большинства типов это UB при малейшем расхождении layout. Особенно опасны trait objects: `&dyn Trait` - толстый указатель (data, vtable), но порядок и стабильность layout не гарантированы между версиями rustc.

Безопасные альтернативы: `as` для числовых конверсий, `std::ptr::from_raw_parts` для построения слайсов из частей, `std::mem::transmute_copy` для случаев, когда нужно избежать move, `bytemuck::cast` для типов с `Pod`.

Если transmute неизбежен, изолируйте его в небольшую `unsafe fn` с тщательно описанными требованиями (`# Safety`-блок в doc-комментарии), и пишите `assert_eq!(size_of::<A>(), size_of::())` для ловли изменений layout в CI.

#### A20. Send/Sync soundness: когда unsafe impl допустим и как его обосновать

Auto-вывод `Send`/`Sync` опирается на состав полей. Если у вашего типа есть поле, формально снимающее `Send` (например, `*mut T`), но логически тип всё равно безопасен, можно написать `unsafe impl Send for MyType {}`. Слово unsafe здесь означает: вы обязуетесь поддерживать инварианты, которые компилятор больше не проверяет.

Что обязан гарантировать автор unsafe impl.

Для `Send`: значение можно «переместить» из одного потока в другой без UB. Если внутри сырой указатель на heap-данные, эти данные не должны иметь thread-local references; деструктор должен корректно работать в произвольном потоке.

Для `Sync`: множественный shared-доступ из разных потоков не порождает гонок. Все мутации защищены атомиками или локами; иммутабельные операции корректны.

Пример. `Arc<T>` сам `Send + Sync` при `T: Send + Sync`, но реализация атомарных счётчиков внутри обоснована вручную. Если бы счётчики были обычные, `Arc` был бы unsound.

Документация. У всех `unsafe impl Send`/`Sync` должен быть комментарий с обоснованием. Это первое, что смотрят на ревью кода библиотек.

### Архитектура высокого уровня

#### A21. Lock-free SPSC ring buffer: какие atomic operations нужны

Single-Producer Single-Consumer ring buffer - классическая задача. Один поток пишет, другой читает, никаких локов.

Минимальный набор. Два индекса `head` и `tail` как `AtomicUsize`. Producer читает свой `tail` (Relaxed - только он пишет), читает `head` (Acquire - чтобы видеть прогресс consumer), пишет данные в слот, обновляет `tail` через `store` с `Release` (чтобы consumer увидел данные).

Consumer симметрично: читает свой `head` (Relaxed), читает `tail` (Acquire), читает данные, обновляет `head` со `store` (Release).

Подводные камни. False sharing: `head` и `tail` должны быть на разных кеш-линиях, иначе CPU постоянно инвалидирует кеш противоположного потока. `#[repr(align(64))]` или `crossbeam_utils::CachePadded` решают.

ABA проблема в SPSC отсутствует (только один producer и один consumer), но появляется в MPMC, и там нужны теги версии или hazard pointers.

## Сколько времени занимает подготовка

Оценки честные, по опыту реальной подготовки. Три колонки: «база» - заходит в Rust почти с нуля, читает The Book параллельно; «средне» - senior на других языках, знает системные концепты; «быстро» - уже senior Rust, готовится к собесу на staff, делает рефреш и упор на сложные темы.

Цифры в часах активной работы (читать, разбирать, писать примеры, прогонять через cargo, гуглить непонятное). Не календарных дней. Реальный темп 1-3 часа в день, итого календарь умножайте на 3-5.

### Макро-план по разделам

| Раздел | База | Средне | Быстро |
| --- | --- | --- | --- |
| Владение, заимствование, лайфтаймы (1-15) | 20-30 ч | 8-12 ч | 3-5 ч |
| Типы, трейты, обобщения (16-30) | 18-25 ч | 7-10 ч | 3-4 ч |
| Конкурентность и параллелизм (31-45) | 20-30 ч | 10-14 ч | 4-6 ч |
| Async и runtime (46-62) | 25-35 ч | 12-18 ч | 6-10 ч |
| Unsafe, FFI, низкий уровень (63-78) | 20-30 ч | 10-15 ч | 5-8 ч |
| Производительность (79-89) | 12-18 ч | 6-10 ч | 3-5 ч |
| Макросы и метапрограммирование (90-95) | 10-15 ч | 5-8 ч | 2-4 ч |
| Архитектура и дизайн API (96-100) | 8-12 ч | 4-6 ч | 2-3 ч |
| Продвинутые вопросы (A1-A21) | 25-40 ч | 12-20 ч | 6-12 ч |
| Итого | 158-235 ч | 74-113 ч | 34-57 ч |

В календаре. База - 3-5 месяцев в темпе 1-2 часа в день. Средне - 6-10 недель. Быстро - 2-4 недели.

Что съедает время сильнее всего у каждой категории.

База - лайфтаймы, async, unsafe. Эти три темы дают 60% времени потому что построены на интуициях, которых в других языках нет. Конкретно лайфтаймы первые 5-10 часов вообще не «щёлкают», потом резко становятся понятнее.

Средне - async cancellation, Send/Sync через await, lock-free паттерны. Концепции знакомы по другим языкам, но Rust требует точности в типах, и здесь садятся часы на споры с компилятором.

Быстро - продвинутые темы (GAT, HRTB, Pin internals, variance, Stacked Borrows). По остальным разделам тратится время на восстановление формулировок и проговаривание.

### Микро-чек на один вопрос

Одна сессия с одним вопросом раскладывается так. Цифры в минутах.

| Этап | База | Средне | Быстро |
| --- | --- | --- | --- |
| Прочитать вопрос, попробовать ответить «в голове» | 5 | 3 | 2 |
| Прочитать разбор в README | 10-15 | 5-8 | 3-5 |
| Скопировать пример в cargo, запустить | 5-10 | 3-5 | 2-3 |
| Сломать пример, посмотреть ошибку компилятора | 10-20 | 5-10 | 3-5 |
| Прочитать смежные источники (rustdoc, Reference) | 15-30 | 5-15 | 3-8 |
| Записать своими словами в заметки | 10-15 | 5-8 | 2-5 |
| Итого на вопрос | 55-95 мин | 26-49 мин | 15-28 мин |

Это для типичного вопроса. Тяжёлые (lifetimes elision, pin projection, memory ordering, soundness pitfalls) умножайте на 1.5-2. Лёгкие (Copy/Clone, From/Into, базовые трейты) делятся на 2.

Что реально ускоряет.

Запуск примеров локально. Чтение «в голове» даёт иллюзию понимания, компилятор её разбивает. Один запущенный пример экономит час споров на собесе.

Заметки своими словами. Перепеть разбор в одно-два предложения как будто объясняете коллеге. Это и проверка понимания, и шпаргалка для повторения.

Mini-проекты по разделу. После 10-15 вопросов решить одну задачу из `tasks/`, она склеит темы в голове лучше, чем ещё 5 вопросов.

Что съедает время впустую.

Чтение нескольких источников по одному вопросу до устойчивого понимания. Достаточно одного, но действительно понятого.

Споры с компилятором без `cargo expand` и без чтения сообщений целиком. Rustc-сообщения длинные неспроста, в них почти всегда есть подсказка fix-ом.

Параллельное изучение нескольких сложных тем (async + unsafe + macros одновременно). Лучше последовательно, иначе ничего не оседает.

### Что делать, если времени мало

Две недели до собеседования и нужен быстрый покрывающий проход.

День 1-3. Владение, заимствование, лайфтаймы, базовые трейты (вопросы 1-30). 4-5 часов в день.

День 4-6. Конкурентность и async (31-62). Минимум один практический пример с `tokio::select!` и одним `Arc<Mutex<T>>`.

День 7-9. Unsafe, FFI, производительность (63-89). Прогнать один пример через Miri, посмотреть один `cargo bench`.

День 10-11. Макросы и архитектура (90-100). Быстро, читать как cheatsheet.

День 12-13. Продвинутые вопросы (A1-A21) выборочно по позиции. Staff-собес - все. Senior - в первую очередь A6-A14.

День 14. Mock-собес или решение задачи из `tasks/` с таймером. На реальном собесе важна не глубина каждого ответа, а скорость попадания в суть.

## 📚 Полезные ресурсы

### 📺 Telegram-каналы и подборки

[t.me/rust_code](https://t.me/rust_code) — основной канал по Rust на русском, уроки и разборы кода. Подходит и для тех, кто заходит с нуля, и для тех, кто освежает темы перед собесом на staff.

[t.me/machinelearning\_interview](https://t.me/+K4iDnNQvdbo5OGQy) — AI, ML и вайбкодинг: разборы интервью, инструменты, как работать с LLM в реальных проектах. Полезно рядом с Rust-стеком, особенно если работаешь с Candle, Burn, Polars или занимаешься AI-инфраструктурой.

[t.me/books_englishhh](https://t.me/books_englishhh) - англоязычные книги и материалы по Rust. Полезно, когда нужно достать конкретное издание (Programming Rust, Zero to Production, Rust for Rustaceans).

[t.me/ai_machinelearning_big_data](https://t.me/ai_machinelearning_big_data) - AI, ML, Big Data. Релевантно при работе с Rust-ML стеком: `candle`, `burn`, `tch-rs`, `linfa`, `polars`.

Папка с обучающими ресурсами - большая подборка каналов для разработчиков, удобно держать одним списком.

## Полезные ссылки

### Roadmap и собеседования

[Develp10/rust-roadmap-ru](https://github.com/Develp10/rust-roadmap-ru) - русскоязычный roadmap по Rust: что учить, в каком порядке, какие проекты собирать, по уровням от джуна до senior. Хорошо ложится поверх этого репозитория: roadmap даёт «куда идти», а здесь - «что спрашивают, когда придёшь».

### Официальные источники

[The Rust Programming Language (The Book)](https://doc.rust-lang.org/book/) - основная книга, читается первой. Покрывает 70% базовых вопросов из разделов 1-30.

[Rust by Example](https://doc.rust-lang.org/rust-by-example/) - короткие примеры по всем темам. Удобно как справочник, когда забыл синтаксис.

[The Rustonomicon](https://doc.rust-lang.org/nomicon/) - книга про unsafe Rust, variance, Drop check, exception safety, FFI. Прямо отвечает на половину вопросов из разделов A1-A20.

[Asynchronous Programming in Rust](https://rust-lang.github.io/async-book/) - официальная async-book. Pin, Future, executor, базовый `tokio`.

[The Rust Reference](https://doc.rust-lang.org/reference/) - формальное описание языка. Туда лезть, когда хочется понять «как это устроено по букве спецификации».

[Standard Library Documentation](https://doc.rust-lang.org/std/) - rustdoc стандартной библиотеки. Лучшая привычка - читать source через кнопку «source» прямо в API-доках.

[Rust Edition Guide](https://doc.rust-lang.org/edition-guide/) - что меняется между editions, как мигрировать.

### Углублённое чтение

[Crust of Rust (Jon Gjengset)](https://www.youtube.com/playlist?list=PLqbS7AVVErFiWDOAVrPt7aYmnuuOLYvOa) - YouTube-серия с разбором стандартной библиотеки в реальном времени. Лучший разбор лайфтаймов, итераторов, channels, async в формате видео.

[Learn Rust With Entirely Too Many Linked Lists](https://rust-unofficial.github.io/too-many-lists/) - книга про писание связных списков на Rust. Через это упражнение поднимаются почти все темы из разделов 1-15 и 63-78.

[Async-await internals: a series by Tyler Mandry](https://tmandry.gitlab.io/blog/posts/optimizing-await-1/) - как устроена компиляция `async fn` в state machine. Прямо отвечает на A9.

[Rust Atomics and Locks (Mara Bos)](https://marabos.nl/atomics/) - книга по конкурентности, memory ordering, lock-free структурам. Бесплатно онлайн. Закрывает разделы 31-45 и продвинутые A12-A15.

[Rust Performance Book](https://nnethercote.github.io/perf-book/) - сборник практик по оптимизации, профилированию, измерению.

[Rust API Guidelines](https://rust-lang.github.io/api-guidelines/) - официальный чек-лист дизайна публичного API. Полезно перед собесом на staff-уровне.

### Спецификации и unsafe

[Unsafe Code Guidelines (UCG)](https://rust-lang.github.io/unsafe-code-guidelines/) - текущее состояние того, что считается UB, что нет, какие модели обсуждаются.

[Stacked Borrows / Tree Borrows](https://plv.mpi-sws.org/rustbelt/stacked-borrows/) - формальные модели алиасинга, которые проверяет Miri.

[Miri](https://github.com/rust-lang/miri) - интерпретатор MIR, ловит UB в unsafe-коде. Запускайте `cargo +nightly miri test` хотя бы раз перед мержем unsafe-кода.

[Loom](https://github.com/tokio-rs/loom) - model checker конкурентного кода.

### Регулярные источники

[This Week in Rust](https://this-week-in-rust.org/) - еженедельная рассылка. RFC, релизы, статьи. Один выпуск в неделю - и вы в курсе экосистемы.

[Rust Blog](https://blog.rust-lang.org/) - официальный блог релизов и анонсов.

[Inside Rust Blog](https://blog.rust-lang.org/inside-rust/) - блог команд разработки компилятора. Полезно для глубокого понимания, куда движется язык.

[Without Boats](https://without.boats/) - блог Boats про async, Pin, и дизайн стандартной библиотеки. Технически плотный.

### Практика

[Exercism Rust Track](https://exercism.org/tracks/rust) - задачи с менторингом. Хорошо для разогрева на интервью с кодингом.

[Rustlings](https://github.com/rust-lang/rustlings) - короткие упражнения для отработки синтаксиса и базовых концептов. На «базовом» уровне обязательно пройти.

[LeetCode на Rust](https://leetcode.com/problemset/all/?topicSlugs=&difficulty=&status=&listId=&languageSlugs=rust) - если на собесе ожидается алгоритмическая часть. Не специфично для Rust, но даёт практику.

[Codecrafters](https://codecrafters.io/) - проекты вроде «build your own Redis on Rust». Платно, но реалистичные задачи близко к продакшну.

### Инструменты, которые стоит держать включёнными

`rustfmt` и `clippy` в pre-commit. Полминуты экономии на ревью, плюс clippy ловит реальные баги.

`cargo expand` (`cargo install cargo-expand`) - смотреть, во что разворачиваются макросы. Незаменимо для отладки proc-macro и понимания async/await.

`cargo asm` - смотреть, во что превращается hot-path. Полезно при подготовке к разделу 79-89.

`cargo flamegraph` - профилирование. Один прогон даёт больше, чем теория про оптимизации.

`cargo audit` - проверка зависимостей на CVE. Тривиально, но иногда спрашивают.

## Что почитать и попробовать руками

The Rust Programming Language. Базовая книга, на которой почти каждый начинал. Rust by Example. Подборка коротких примеров, удобно подсматривать синтаксис. Rust Atomics and Locks от Mara Bos. Лучший разбор всего, что связано с памятью и многопоточностью. Async Book. Объясняет, как async устроен изнутри, без неё писать свои фьючи довольно сложно. The Rustonomicon. Все, что нужно знать про unsafe, на одном месте. Документация tokio. Часто отвечает на вопросы быстрее, чем поиск по статьям.

Из инструментов. `cargo expand` показывает, во что разворачивается код после макросов, помогает в отладке и в обучении. `cargo asm` показывает ассемблер конкретной функции, незаменим при оптимизации. `miri` ловит UB в unsafe коде. `loom` проверяет конкурентные алгоритмы под разными перестановками. `clippy` и `rustfmt` должны быть в CI любого проекта. `cargo udeps` находит неиспользуемые зависимости. Этой минимальной обвязки хватает и для подготовки, и для повседневной работы.

## Контрибьютинг

Если заметили ошибку, неточность или хотите дополнить разбор, открывайте issue или присылайте pull request. Подробности в файле `CONTRIBUTING.md`. Для нового вопроса лучше сначала обсудить его в issue, чтобы не делать двойную работу. Стиль текста и формат разбора стараемся держать в одном ключе. Без воды, без АИ клише, с практическим уклоном и рабочими примерами.

## Лицензия

MIT. Подробнее см. файл [`LICENSE`](./LICENSE).

rustinterviewquiestions

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README