Как сравнить Tokio (Rust) с альтернативами по надёжности, скорости разработки, portability, performance и operational cost?

Конкуренты и критерии сравнения

Основные async runtime для Rust: Tokio, async-std, smol, glommio (io_uring). Каждый делает разные трейдоффы.

Performance

• Tokio: work-stealing scheduler, оптимизирован для high-throughput. В бенчмарках TechEmpower Plaintext — стабильно в топ-5 среди всех языков (axum/actix-web).
• glommio: io_uring + thread-per-core без work-stealing. Лучший latency-percentile (p99) для disk I/O, но только Linux 5.8+.
• smol: минималистичный runtime, сравнимый throughput с Tokio для простых сценариев, но без work-stealing в базовой конфигурации.
• async-std: исторически медленнее Tokio на 10–30% в нагрузочных тестах из-за другой архитектуры планировщика.

Скорость разработки

// Tokio: богатая stdlib-подобная экосистема
use tokio::{
    net::TcpStream,
    sync::{mpsc, Mutex, RwLock, Semaphore, broadcast},
    time::{sleep, timeout, interval},
    fs,
    process::Command,
};
// Все примитивы в одном крейте — не нужно искать аналоги

• Tokio: самая богатая экосистема. axum, tonic, sqlx, reqwest, lapin — всё спроектировано под Tokio. Меньше времени на «склейку» зависимостей.
• async-std: API максимально похож на std (async версии std::fs, std::net), проще для знающих std.
• smol: нужно самостоятельно выбирать async-channel, async-io, async-executor — гибкость, но и больше решений.

Надёжность

• Tokio: production-battle-tested в AWS Lambda, Discord (миллионы WebSocket), Cloudflare Workers. MSRV политика стабильна.
• glommio: используется в ScyllaDB Rust драйвере, но экосистема мала.
• async-std: развитие замедлилось после 2021, часть команды перешла в smol-экосистему.

Portability

• Tokio: Windows (IOCP), macOS (kqueue), Linux (epoll). WASM через wasm-bindgen-futures.
• glommio: только Linux с io_uring — жёсткое ограничение для cross-platform.
• smol: аналогично Tokio, кроссплатформенный через polling крейт.

Operational cost

• Tokio: сложнее дебажить без tokio-console. Зато метрики через tokio::runtime::Handle::current().metrics() доступны в runtime.
• smol/async-std: проще для понимания команды, меньше «магии», но и меньше инструментов диагностики.

Подводные камни

• Vendor lock-in экосистемы: крейты, написанные под Tokio, часто не работают с async-std и наоборот из-за разных типов Sleep, TcpStream и т.д.
• glommio на prod требует ядро >=5.8: на старых Ubuntu LTS (20.04 = 5.4) он недоступен.
• Миграция между runtime крайне болезненна: замена Tokio на smol в зрелом проекте требует замены всех типов io, sync и time — фактически переписывание.
• Benchmark selection bias: TechEmpower тестирует plain HTTP, но для реального gRPC или Kafka streaming картина может быть другой.
• async-std MSRV нестабилен: несколько раз ломал сборки при обновлении зависимостей.
• smol без work-stealing: при CPU-bound spike одна задача может монополизировать поток.
• Tokio multi-thread runtime на embedded: не подходит без std. Для embedded нужен Embassy или current_thread flavour.

• Сравнивать Tokio (Rust) с альтернативами по одному признаку
• Путать личную привычку с инженерным критерием выбора
• Не учитывать migration cost и vendor/ecosystem lock-in

• Сравнивает Tokio (Rust) по нескольким инженерным осям
• Не путает популярность с пригодностью
• Понимает migration cost и долгосрочную поддержку