Привет, форумчане. Хочу поделиться личным опытом, а не пересказом чужих бенчмарков. Последние четыре года я пишу бэкенды на Go, и почти два года назад начал всерьёз трогать Rust. За это время я успел сделать один и тот же высоконагруженный сервис на обоих языках, и сравнивать их на бумаге больше не хочется — гораздо честнее сравнивать их руками, когда в продакшене падают коннекты, а в графиках латентности появляются девяносто девятые процентили, которые никто не ждал.
Начну с контекста. У нас был сервис-агрегатор: примерно тридцать тысяч запросов в секунду в пике, куча сетевого ввода-вывода, много JSON, обращение к нескольким базам и внешним API, жёсткий бюджет по задержке в районе десяти миллисекунд. Первую версию я написал на Go, и она, честно говоря, взлетела. Горутины, каналы, простой HTTP-стек, быстрая сборка, понятный профайлер. За три недели я получил работающий сервис, который держал нагрузку и почти не требовал внимания. Вот это ощущение скорости разработки — главный козырь Go, и в 2025 году он никуда не делся.
Но потом начались детали. Проблема была не в среднем времени ответа, а в хвостах. Сборщик мусора в Go работает очень хорошо, но он всё равно останавливает мир, пусть и на доли миллисекунды. На нашем профиле с большим количеством короткоживущих объектов я регулярно видел всплески задержки, которые портили девяносто девятый процентиль. Плюс потребление памяти: при пиковой нагрузке сервис съедал в два с половиной раза больше оперативной памяти, чем мне казалось разумным. Можно было это лечить тюнингом, ограничением числа горутин, пулами буферов, но приходилось постоянно думать о том, о чём я не хотел думать.
Тогда я решил переписать горячий путь на Rust. И вот тут началось самое интересное. Первый месяц был болью: заимствования, времена жизни, борьба с компилятором, который отказывался собирать то, что в Go компилировалось без единого вопроса. Я переписывал одни и те же двадцать строк по пять раз. Но когда оно собралось, оно просто работало — без утечек, без сюрпризов, с предсказуемым потреблением памяти. Асинхронный рантайм вроде Tokio уже устоялся, экосистема крейтов в 2025 году выглядит зрелой, и то, что год назад приходилось писать руками, сейчас лежит готовым.
Что я получил в цифрах и ощущениях. По пропускной способности Rust дал примерно в полтора-два раза больше на том же железе, но честно скажу: это был не главный выигрыш. Главный выигрыш — это хвосты латентности и память. Девяносто девятый процентиль стал ровным, как стол, а потребление памяти упало почти втрое, потому что нет сборщика мусора и нет накладных расходов на его обслуживание. Зато цена — скорость разработки. То, что на Go я делал за день, на Rust я делал за три, а наставников рядом не было. Найм тоже сложнее: сильных Rust-разработчиков на рынке заметно меньше, и стоят они дороже.
Теперь про выбор, который я бы посоветовал вам. Если вы делаете продуктовый бэкенд, у вас небольшая команда, сроки поджимают, а нагрузка исчисляется тысячами, а не сотнями тысяч запросов в секунду — берите Go и не мучайтесь. Он даст вам предсказуемость, простой деплой, огромный пул библиотек и лёгкий вход для новых людей. Если у вас узкое место в задержках, жёсткие требования по памяти, вы работаете с сетью на низком уровне, пишете прокси, очереди, движки обработки данных или платите за каждую гигабайт-секунду в облаке — Rust оправдает вложенные в обучение месяцы. И да, переписывать всё подряд с одного на другой не нужно: у меня в итоге получилась гибридная система, где Go отвечает за бизнес-логику, а Rust держит горячий путь.
Мой главный вывод за эти два года простой: это не противостояние, а два разных инструмента с разной ценой владения. Go покупает вам время разработчиков, Rust покупает вам ресурсы железа и предсказуемость в пике. В 2025 году оба языка хороши настолько, что выбор определяется не модой и не холиваром, а вашим профилем нагрузки, размером команды и тем, сколько вы готовы вложить в обучение. А теперь вопрос к вам: а что вы крутите в продакшене прямо сейчас, и был ли у вас момент, когда вы пожалели о выбранном языке?
Начну с контекста. У нас был сервис-агрегатор: примерно тридцать тысяч запросов в секунду в пике, куча сетевого ввода-вывода, много JSON, обращение к нескольким базам и внешним API, жёсткий бюджет по задержке в районе десяти миллисекунд. Первую версию я написал на Go, и она, честно говоря, взлетела. Горутины, каналы, простой HTTP-стек, быстрая сборка, понятный профайлер. За три недели я получил работающий сервис, который держал нагрузку и почти не требовал внимания. Вот это ощущение скорости разработки — главный козырь Go, и в 2025 году он никуда не делся.
Но потом начались детали. Проблема была не в среднем времени ответа, а в хвостах. Сборщик мусора в Go работает очень хорошо, но он всё равно останавливает мир, пусть и на доли миллисекунды. На нашем профиле с большим количеством короткоживущих объектов я регулярно видел всплески задержки, которые портили девяносто девятый процентиль. Плюс потребление памяти: при пиковой нагрузке сервис съедал в два с половиной раза больше оперативной памяти, чем мне казалось разумным. Можно было это лечить тюнингом, ограничением числа горутин, пулами буферов, но приходилось постоянно думать о том, о чём я не хотел думать.
Тогда я решил переписать горячий путь на Rust. И вот тут началось самое интересное. Первый месяц был болью: заимствования, времена жизни, борьба с компилятором, который отказывался собирать то, что в Go компилировалось без единого вопроса. Я переписывал одни и те же двадцать строк по пять раз. Но когда оно собралось, оно просто работало — без утечек, без сюрпризов, с предсказуемым потреблением памяти. Асинхронный рантайм вроде Tokio уже устоялся, экосистема крейтов в 2025 году выглядит зрелой, и то, что год назад приходилось писать руками, сейчас лежит готовым.
Что я получил в цифрах и ощущениях. По пропускной способности Rust дал примерно в полтора-два раза больше на том же железе, но честно скажу: это был не главный выигрыш. Главный выигрыш — это хвосты латентности и память. Девяносто девятый процентиль стал ровным, как стол, а потребление памяти упало почти втрое, потому что нет сборщика мусора и нет накладных расходов на его обслуживание. Зато цена — скорость разработки. То, что на Go я делал за день, на Rust я делал за три, а наставников рядом не было. Найм тоже сложнее: сильных Rust-разработчиков на рынке заметно меньше, и стоят они дороже.
Теперь про выбор, который я бы посоветовал вам. Если вы делаете продуктовый бэкенд, у вас небольшая команда, сроки поджимают, а нагрузка исчисляется тысячами, а не сотнями тысяч запросов в секунду — берите Go и не мучайтесь. Он даст вам предсказуемость, простой деплой, огромный пул библиотек и лёгкий вход для новых людей. Если у вас узкое место в задержках, жёсткие требования по памяти, вы работаете с сетью на низком уровне, пишете прокси, очереди, движки обработки данных или платите за каждую гигабайт-секунду в облаке — Rust оправдает вложенные в обучение месяцы. И да, переписывать всё подряд с одного на другой не нужно: у меня в итоге получилась гибридная система, где Go отвечает за бизнес-логику, а Rust держит горячий путь.
Мой главный вывод за эти два года простой: это не противостояние, а два разных инструмента с разной ценой владения. Go покупает вам время разработчиков, Rust покупает вам ресурсы железа и предсказуемость в пике. В 2025 году оба языка хороши настолько, что выбор определяется не модой и не холиваром, а вашим профилем нагрузки, размером команды и тем, сколько вы готовы вложить в обучение. А теперь вопрос к вам: а что вы крутите в продакшене прямо сейчас, и был ли у вас момент, когда вы пожалели о выбранном языке?