🦀 Асинхронка 🦀

Я уверен, вы уже привыкли к тому, что в Rust очень много zero-cost абстракций. Асинхронка дополняет список.

Давайте посмотрим, как работать с асинхронными функциями в Rust.🧐

Простой пример - загрузка файла

use tokio;

async fn download_file(url: &str) -> String {
    println!("Начинаю загрузку {}", url);
    let response = reqwest::get(url).await.unwrap();
    println!("Получил ответ!");
    let content = response.text().await.unwrap();
    println!("Загрузил {} байт", content.len());
    content
}

#[tokio::main]
async fn main() {
    let task1 = download_file("https://example.com/file1");
    let task2 = download_file("https://example.com/file2");
    
    // Запускаем параллельно!
    let (content1, content2) = tokio::join!(task1, task2);
}

Код с виду выглядит синхронным, а компилятор под капотом превращает его в эффективный автомат состояний. И никаких накладных расходов в рантайме.

Что происходит под капотом? 🤔

1️⃣ Компилятор создаёт конечный автомат состояний.

Ваша async-функция превращается в enum с состояниями:

// Примерно так видит компилятор вашу функцию
enum DownloadFileState {
    Start {
        url: String,
    },
    WaitingForResponse {
        url: String,
        response_future: ResponseFuture,
    },
    WaitingForText {
        text_future: TextFuture,
    },
    Done,
}

2️⃣ Каждый `.await` - это точка приостановки

Когда вы пишете .await, компилятор:
- Сохраняет текущее состояние функции (все локальные переменные)
- Возвращает управление планировщику
- Запоминает, где продолжить выполнение

// Это:
let response = reqwest::get(url).await;
let content = response.text().await;

// Превращается в переключение между состояниями:
// Start → WaitingForResponse → WaitingForText → Done

Пока одна задача ждёт ответа от сервера, планировщик переключается на другие задачи. Никакого блокирования потока!

3️⃣ Рантайм крутит все задачи

Tokio/async-std работает как диспетчер:
- Опрашивает каждую задачу: "Ты готова продолжить?"
- Если нет → переключается на следующую
- Если да → выполняет следующий кусок кода до .await

Вся работа получается очень быстрой:⚡️
- Можно создать миллионы асинхронных задач
- Переключение = просто вызов функции (наносекунды)
- Нет тяжёлых системных вызовов

И в рантайме получаем только эффективный машинный код! 🚀

🚀 Пост Guru Rust: @PaulEdd

🦀 Десериализация в Rust 🦀

Тоже производительная, как и все остальное в Rust. Все потому, что она zero-copy.

Рассмотрим подробнее 🤨

При работе с большими JSON или бинарными данными традиционная десериализация создаёт копии строк и байтов. Это естественно расходует память. 💀
Система владения в Rust позволяет использовать мощную оптимизацию: zero-copy десериализацию.

Проблема:

// Обычная десериализация - создаёт owned String
#[derive(Deserialize)]
struct User {
    name: String,  // Выделяет новую память
    email: String, // Ещё одна аллокация
}

// При парсинге JSON каждая строка копируется в кучу
let json = r#"{"name": "Иван", "email": "ivan@example.com"}"#;
let user: User = serde_json::from_str(json)?;
// Данные скопированы из json в user.name и user.email

Решение:

// Zero-copy с заимствованными данными
#[derive(Deserialize)]
struct User<'a> {
    #[serde(borrow)]
    name: &'a str,  // Без аллокации!
    #[serde(borrow)]
    email: &'a str,
}

// Теперь данные НЕ копируются
let json = r#"{"name": "Иван", "email": "ivan@example.com"}"#;
let user: User = serde_json::from_str(json)?;
// user.name и user.email просто ссылаются на части json!

Преимущества очевидны 💡:

• Производительность: Устраняем аллокации для строковых/байтовых полей
• Эффективность памяти: Ссылаемся на оригинальный буфер вместо копирования
• Низкие задержки: Критично для высоконагруженных сервисов

⚠️ Но всегда стоит помнить!
Заимствованные данные должны жить дольше вашей структуры. Десериализованный объект не может пережить исходный буфер.

В сочетании с simd-json или похожими библиотеками можно достичь времени парсинга на уровне микросекунд.

Был ли у вас опыт с zero-copy в Rust? 🍷

🚀 Пост Guru Rust: @PaulEdd

🦀 СТАТИЧЕСКИЙ vs. ДИНАМИЧЕСКИЙ полиморфмизм 🦀

На собесах про это часто любят спрашивать. Давайте разберемся, в чем же разница между двумя этими понятиями.

В Rust есть два способа работать с трейтами - и они кардинально отличаются под капотом. 🤑

Статический полиморфизм (с использованием дженериков)

trait Animal {
    fn speak(&self);
}

struct Dog;
struct Cat;

impl Animal for Dog {
    fn speak(&self) { println!("Гав!"); }
}

impl Animal for Cat {
    fn speak(&self) { println!("Мяу!"); }
}

// Статический полиморфизм
fn make_speak<T: Animal>(animal: &T) {
    animal.speak();
}

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

// Компилятор создаёт две версии:
fn make_speak_Dog(animal: &Dog) { ... }
fn make_speak_Cat(animal: &Cat) { ... }

Динамический полиморфизм (с использованием трейт-объектов)

// Динамический полиморфизм
fn make_speak_dyn(animal: &dyn Animal) {
    animal.speak();
}

// Можно хранить разные типы в одной коллекции!
let animals: Vec<Box<dyn Animal>> = vec![
    Box::new(Dog),
    Box::new(Cat),
];

for animal in &animals {
    animal.speak();
}

Здесь компилятор создаёт одну функцию, а нужный метод ищется в рантайме через vtable (таблицу виртуальных методов).


Когда что использовать? 🤨

Статический полиморфизм:
- Максимальная производительность. Никаких накладных расходов в рантайме
- Компилятор знает конкретный тип
- Но: раздувает бинарник (код дублируется для каждого типа)

Динамический полиморфизм:
- Больше гибкость. Можно хранить разные типы в одной коллекции
- Меньше размер бинарника
- Но: косвенный вызов через vtable (небольшой оверхед)
- Но: нельзя использовать с не-object-safe трейтами

Что чаще используете - дженерики или трейт-объекты?

🚀 Пост Guru Rust: @PaulEdd