👣👣 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/