👣👣 Discord объяснил, почему часть инфраструктуры переходит с Go на Rust
Discord начал переносить отдельные компоненты с Go на Rust, потому что при их масштабе главная цена - это предсказуемость задержек и эффективность памяти. Речь не про "мода на Rust", а про конкретные технические потолки, в которые упираются большие real-time системы.
Контекст - почему это вообще стало проблемой
Discord - это нагрузка с постоянными пиками и жёсткими требованиями к latency. Когда у тебя миллионы одновременных соединений, сообщения в реальном времени, голосовые сессии и огромные объёмы событий, любая нестабильность по времени ответа превращается в пользовательские лаги и дорогую инфраструктуру.
Что в Go стало упираться на масштабе Discord
1) GC и хвостовые задержки
Go использует сборщик мусора. Он стал очень хорошим, но у больших сервисов с активными аллокациями и большими heap-объёмами GC всё равно может:
- создавать краткие паузы или "подёргивания"
- давать спайки по p99 и p999 latency
- делать поведение менее предсказуемым именно в моменты пиков
На небольших сервисах это часто незаметно. На real-time инфраструктуре, где важны хвостовые перцентили, это начинает быть системной проблемой.
2) Цена аллокаций и давление на память
Go удобен, но он поощряет стиль, где аллокации происходят "само собой". На горячих путях это приводит к:
- росту heap
- большему количеству работы GC
- большему потреблению RAM
- а значит - к большему числу машин и более высокой стоимости
3) Потребность в более низком уровне контроля
В некоторых компонентах Discord понадобился контроль над:
- тем, когда и как выделяется память
- буферами и их жизненным циклом
- layout данных
- оптимизациями "вплоть до байта"
Go как язык намеренно ограничивает такие вещи ради простоты и скорости разработки. Когда система доросла, Discord понадобилось больше "ручек".
Почему именно Rust
1) Нет GC - стабильнее latency
Rust не использует сборщик мусора. Память освобождается детерминированно через владение и области видимости.
Результат - меньше неожиданных спайков по времени ответа, особенно на больших heap-нагрузках.
2) Контроль над аллокациями и структурой данных
Rust позволяет проектировать горячие пути так, чтобы:
- уменьшать количество аллокаций
- переиспользовать буферы
- держать данные в более cache-friendly структурах
- снижать overhead на каждом запросе/событии
3) Производительность уровня системного программирования с безопасностью
Discord явно не хочет возвращаться в мир "C/C++ и вечных memory bugs". Rust даёт:
- системную производительность
- защиту от use-after-free, data races и многих классов ошибок памяти на уровне компилятора
Главный нюанс - Discord не "выкинул Go"
Важная мысль из текста Discord: это не религия, а прагматика.
Обычно выглядит так:
- Go остаётся отличным для продуктовой логики, быстрых сервисов, разработки и поддержки
- Rust применяют там, где есть жёсткий performance budget - горячие пути, сетевые компоненты, обработка больших объёмов событий, инфраструктурные библиотеки
То есть это "гибридная стратегия", а не миграция всего подряд.
Что это говорит о рынке
1) Go закрепился как язык для скорости разработки
Если цель - быстро писать и менять микросервисы, Go остаётся одним из лучших выборов.
2) Rust всё чаще становится языком инфраструктуры
Когда компания вырастает и начинает платить миллионы за лишние миллисекунды и гигабайты RAM, Rust становится экономически выгодным.
3) Критерий выбора меняется с "удобно" на "предсказуемо"
На больших масштабах выигрывает не тот, кто чуть быстрее в среднем, а тот, у кого меньше хвостовых задержек и меньше сюрпризов под нагрузкой.
История Discord - это не про - "Go плохой". Это кейс о том, что на hyperscale появляются другие ограничения.
Go - отличный default для backend.
Rust - сильный инструмент для performance-critical инфраструктуры, где важны p99/p999, память и контроль над горячими путями.
https://discord.com/blog/why-discord-is-switching-from-go-to-rust/
