Подготовка к собеседованию — Rust-разработчик

Короткий ответ: Трейты дают полиморфизм в стиле интерфейсов — с методами по умолчанию и blanket-реализациями. Супертрейт — это обязательство «реализуй ещё и тот трейт», а не наследование полей и поведения. Переиспользование кода в Rust строится на композиции: вкладываешь тип в структуру и делегируешь (в т. ч. через Deref).

Подробно:

1. Полиморфизм — общий интерфейс через trait + дефолтные методы; статически (дженерики) или динамически (dyn).
2. Blanket impl — impl<T: Display> ToString for T даёт ToString сразу всем Display-типам — переиспользование без иерархии.
3. Супертрейт ≠ наследование — trait B: A требует реализовать и A, но не наследует его состояние; это ограничение, а не «is-a».
4. Композиция — поля-компоненты + делегирование методов заменяют цепочки классов; «has-a» вместо «is-a».

⚠️ Частая ошибка: называть супертрейт «наследованием». Он не тянет за собой поля и реализацию — это лишь требование реализовать другой трейт.

Короткий ответ: Box<T> — единоличный владелец, обычная аллокация в куче с нулевой стоимостью разыменования. Rc<T> — разделяемое владение через неатомарный счётчик ссылок, только внутри одного потока. Arc<T> — то же разделяемое владение, но счётчик обновляется атомарно, поэтому его можно шарить между потоками (ценой атомарных операций).

Подробно:

1. Box<T> — один владелец, счётчика нет. Нужен, когда значение должно лежать в куче: рекурсивные структуры, трейт-объекты (Box<dyn Trait>), большие значения. Разыменование бесплатно.
2. Rc<T> — несколько владельцев в одном потоке. clone() инкрементит strong-счётчик, drop декрементит; данные освобождаются при достижении нуля. Отдаёт только &T — для мутации кладут RefCell внутрь.
3. Arc<T> — как Rc, но счётчик на атомиках (fetch_add/fetch_sub). Реализует Send/Sync, годится для многопоточки; для мутации оборачивают в Mutex/RwLock.

⚠️ Частая ошибка: тянуть Arc везде «на всякий случай». Если владелец один — хватит Box или вообще стека; атомарные операции Arc не бесплатны, а в одном потоке это чистые накладные расходы.

Короткий ответ: Option<T> — когда значение может просто отсутствовать и причина неважна (Some/None). Result<T, E> — когда операция может завершиться ошибкой и вызывающему нужна причина сбоя (Ok/Err).

Подробно:

1. Option — моделирует «значения может не быть»: HashMap::get не нашёл ключ, Vec::first на пустом векторе. None не несёт информации о причине.
2. Result — моделирует «операция провалилась»: File::open не нашёл файл, str::parse не смог распарсить. Err(e) объясняет, что пошло не так.
3. Конвертация — они легко переходят друг в друга: option.ok_or(err) превращает None в Err, а result.ok() отбрасывает ошибку и даёт Option.

⚠️ Частая ошибка: возвращать Result там, где отсутствие — норма (или Option там, где нужна причина сбоя). «Ключа нет» — это Option, а не ошибка.

Короткий ответ: Send означает, что владение значением можно безопасно передать в другой поток; Sync — что &T можно безопасно шарить между потоками (по определению T: Sync ⇔ &T: Send). Это авто-трейты (auto traits): компилятор реализует их структурно — тип Send/Sync, если все его поля Send/Sync. Ничего писать руками не надо.

Подробно:

1. Структурный вывод — авто-трейт распространяется по полям: структура из Send-полей сама Send. Сырые указатели (*const T, *mut T) осознанно отказываются от обоих трейтов, из-за чего типы поверх них тоже теряют их.
2. unsafe impl — если ты гарантируешь потокобезопасность вручную (например, обернул сырой указатель в корректную синхронизацию), можно unsafe impl Send for MyType {}. Это утверждение под твою ответственность: компилятор проверить его не может.
3. Явный отказ — negative impl (impl !Send for T) доступен только на nightly; так Rc помечен внутри std. На stable трейт снимают маркерным полем вроде PhantomData<*const ()> (!Send + !Sync).

⚠️ Частая ошибка: думать, что Send и Sync — про «многопоточность типа вообще». Send — про перемещение владения между потоками, Sync — про разделяемый доступ по ссылке; это разные гарантии, и тип может иметь одну без другой.

Короткий ответ: Future — это ленивая стейт-машина, реализующая трейт Future с методом poll. Вызов async fn не запускает работу, а лишь конструирует объект футуры. Код внутри начинает выполняться, только когда футуру опрашивает (poll) исполнитель — то есть когда вы её .await-ите или отдаёте в spawn.

Подробно:

1. async fn возвращает значение — тип impl Future<Output = T>. Сам вызов — это конструктор стейт-машины, а не старт вычисления.
2. Ленивость — в отличие от потока, футура не крутится в фоне сама по себе. Пока её никто не poll-ит, она инертна.
3. Кто двигает футуру — .await внутри другой async-функции или tokio::spawn, который отдаёт задачу рантайму. Без этого работа не начнётся.

async fn work() { println!("побежали"); }

let fut = work(); // ничего не произошло — печати нет
fut.await;        // вот теперь тело реально выполнилось

⚠️ Частая ошибка: ждать, что async fn стартует «как поток» сразу при вызове. Забытый .await — это не запущенная работа, а нередко и предупреждение unused_must_use: «futures do nothing unless you .await or poll them».