Go и Rust по производительности: когда разница важна

Go и Rust оба могут быть быстрыми, но они быстрые по-разному. Go обычно дает хорошую производительность при высокой скорости разработки. Rust дает больше контроля над памятью, предсказуемостью и низкоуровневой оптимизацией, но требует больше усилий от разработчика. Поэтому вопрос «что быстрее» не всегда помогает. Гораздо полезнее спросить: «какая производительность нужна именно этому проекту и где у него реальное узкое место»

В обычном backend-сервисе разница между Go и Rust может оказаться несущественной, потому что узкое место будет в базе данных, сети, внешнем API, очереди или неверной архитектуре. В системном компоненте, парсере, сетевом прокси, обработчике больших потоков данных или библиотеке разница может стать заметной

Если вам нужно принять решение, не опирайтесь только на чужие бенчмарки. Они полезны как ориентир, но ваш проект может упираться совсем в другое. Сделайте маленький прототип, измерьте задержки, память и throughput, а потом принимайте решение

Быстрая развилка по производительности

Разница обычно не важна, если сервис большую часть времени ждет базу данных, внешний API, очередь, сеть или файловую систему. В такой ситуации Rust не исправит медленный SQL-запрос, лишний HTTP-вызов или неудачное кеширование. Go часто будет рациональнее, потому что команда быстрее найдет и устранит системные узкие места

Разница может быть важна, если основная работа происходит внутри процесса: парсинг больших файлов, обработка бинарных данных, сетевой прокси, сжатие, криптография, горячий цикл, строгие p99-задержки, ограниченная память или большое количество коротких операций. Здесь Rust стоит рассматривать серьезнее, потому что контроль памяти и отсутствие GC могут дать реальный эффект

Самый полезный вопрос звучит так: что именно мы измеряем? Если ответа нет, выбор языка преждевременный. Сначала нужны целевые цифры: например, p99 ниже 50 мс, обработка файла до 2 минут, память ниже 128 МБ или 10 тысяч событий в секунду на одном процессе

Почему Rust часто быстрее в низкоуровневых задачах

Rust не использует сборщик мусора. Управление памятью строится вокруг владения, заимствования и времени жизни значений. Это позволяет писать код, который работает близко к уровню C и C++, но с большим количеством проверок на этапе компиляции

В задачах, где важно контролировать выделения памяти, копирование данных, lifetime буферов и отсутствие пауз сборщика мусора, Rust может дать преимущество. Особенно это заметно в:

• парсинге больших файлов;
• сетевых протоколах;
• системных утилитах;
• криптографических и security-компонентах;
• обработке бинарных данных;
• высокочастотных сервисах с жесткими требованиями к задержкам;
• библиотеках, которые вызываются очень часто

Но важно понимать цену. Rust не делает код быстрым автоматически. Нужно выбирать правильные структуры данных, избегать лишних аллокаций, понимать async-модель, профилировать и проверять реальные сценарии. Если команда пишет неоптимальный Rust, результат может быть хуже, чем аккуратный Go

По этой теме полезно отдельно посмотреть Как я создал безопасные Firebase Cloud Functions с правами администратора и ограничением частоты запросов, чтобы расширить контекст и сравнить подходы

По этой теме полезно отдельно посмотреть Go и Rust: что выбрать для проекта, чтобы расширить контекст и сравнить подходы

Почему Go часто достаточно быстрый

Go использует сборщик мусора, но для множества серверных задач это не проблема. Современный Go хорошо справляется с API, микросервисами, воркерами, очередями, CLI и сетевыми программами. Его производительности часто достаточно с большим запасом

Go особенно силен там, где важна не максимальная скорость одной операции, а общая скорость разработки и эксплуатации. Вы быстро пишете сервис, легко собираете бинарник, подключаете логирование, метрики, HTTP, базы данных и отправляете приложение в production

Для типичного backend-проекта Go может оказаться лучшим выбором именно потому, что его проще оптимизировать на уровне системы: добавить кеш, исправить SQL-запрос, уменьшить количество сетевых вызовов, настроить пул соединений, убрать лишнюю сериализацию. Эти изменения часто дают больше эффекта, чем переход на другой язык

Что именно измерять

Производительность — это не одно число. Перед сравнением Go и Rust нужно определить, что для вас важно:

1. Throughput: сколько запросов или операций выполняется в секунду
2. Latency: сколько времени занимает один запрос
3. p95 и p99: как ведут себя самые медленные запросы
4. Memory usage: сколько памяти потребляет процесс
5. CPU usage: сколько процессорного времени нужно для нагрузки
6. Startup time: как быстро программа стартует
7. Binary size: насколько важен размер бинарника
8. Predictability: бывают ли резкие паузы и скачки задержки

Для веб-сервиса часто важны p95, p99, память и стабильность под нагрузкой. Для CLI-инструмента может быть важнее время запуска и обработки файла. Для embedded-компонента важны память и контроль ресурсов. Для аналитического batch-процесса важны throughput и CPU

Если не выбрать метрики заранее, сравнение будет хаотичным. Один человек будет говорить про скорость обработки, другой про память, третий про простоту кода

Пример: HTTP API

Представим простой HTTP API, который принимает запрос, читает данные из базы и возвращает JSON. В такой задаче язык приложения часто не является главным узким местом. Запрос к базе может занимать миллисекунды, сеть добавляет задержку, сериализация JSON тоже влияет, но редко именно Go или Rust становятся решающим фактором

В этом сценарии Go обычно достаточно. Он быстро позволяет написать понятный сервис, подключить роутер, middleware, логирование и метрики. Rust тоже справится, но команда может потратить больше времени на типы, async runtime и обработку ошибок

Когда Rust может стать важен в HTTP API? Например, если сервис обрабатывает огромный поток запросов с минимальной логикой, работает на ограниченных ресурсах или требует очень низких задержек. Но даже тогда сначала стоит профилировать. Возможно, проблема в базе, JSON, аллокациях или сетевой конфигурации

Пример: парсер больших файлов

Теперь другой сценарий: программа читает многогигабайтный файл, разбирает строки, извлекает поля, фильтрует данные и пишет результат. Здесь язык и работа с памятью могут играть гораздо большую роль

Rust может дать преимущество, потому что позволяет аккуратно работать с буферами, избегать лишних копий и контролировать выделения памяти. Go тоже может быть быстрым, особенно если писать аккуратно: использовать buffered I/O, не создавать лишние строки, не держать весь файл в памяти

Практический тест для такого проекта:

• файл на 1-5 ГБ;
• одинаковый формат входных данных;
• одинаковый формат результата;
• измерение времени обработки;
• измерение максимального потребления памяти;
• проверка корректности результата

Если Rust дает заметный выигрыш, а проект действительно упирается в обработку файла, выбор может быть оправдан. Если разница небольшая, а Go проще для команды, возможно, Go останется лучшим решением

Пример: сетевой сервис с низкими задержками

Если сервис должен отвечать очень быстро и стабильно, важны не только средние значения, но и хвосты задержек. Средняя задержка может быть хорошей, а p99 плохим. Для пользователя или другой системы это означает, что часть запросов иногда зависает

Сборщик мусора Go может влиять на задержки, хотя в современных версиях он достаточно хорош. Rust не имеет GC-пауз, но async-код, блокировки, аллокации и неправильная архитектура все равно могут создавать проблемы

Для таких задач нужно измерять:

• p50, p95, p99;
• задержки при длительной нагрузке;
• поведение после прогрева;
• влияние аллокаций;
• использование CPU;
• стабильность после нескольких часов работы

Если требования к p99 очень жесткие, Rust может быть интереснее. Если требования обычные для backend-сервиса, Go часто проще и достаточно стабилен

Память и сборщик мусора

Один из главных технических различителей — память. Go выделяет память и освобождает ее через сборщик мусора. Это упрощает разработку: не нужно вручную думать о lifetime каждого значения. Но GC может потреблять ресурсы и в некоторых сценариях влиять на задержки

Rust заставляет думать о владении данными заранее. Это сложнее, но позволяет избежать сборщика мусора. В результате можно писать программы с более предсказуемым использованием памяти

Но и здесь нет магии. В Rust можно делать лишние выделения, неудачно клонировать данные, использовать неподходящие структуры. В Go можно писать очень аккуратно, переиспользовать буферы, уменьшать аллокации и получать отличные результаты

Если память критична, задайте вопросы:

1. Сколько данных обрабатывается одновременно?
2. Можно ли стримить данные, а не хранить все в памяти?
3. Где происходят основные выделения?
4. Есть ли профилировка аллокаций?
5. Нужно ли избегать GC-пауз любой ценой?

Ответы важнее общего мнения о языке

Конкурентность и параллелизм

Go знаменит goroutine. Их легко создавать, и для многих серверных задач это огромный плюс. Можно обрабатывать много соединений, запускать воркеры, читать из каналов, строить простые pipeline. Модель понятная и быстрая для освоения

Rust тоже умеет конкурентность, но требует больше явности. Async-экосистема мощная, но новичку сложнее: нужно понимать runtime, async, await, futures, ownership в асинхронном коде. Зато строгая модель типов помогает ловить часть ошибок раньше

Для обычного сервиса Go часто быстрее доводит concurrent-код до рабочего состояния. Для критичного компонента, где важна строгая безопасность данных и контроль ресурсов, Rust может быть надежнее

Не выбирайте язык только по модели конкурентности. Сначала опишите, что именно нужно: тысячи соединений, CPU-bound обработка, очереди, параллельный парсинг, фоновые задачи. Разные сценарии требуют разной архитектуры

Как провести честный мини-бенчмарк

Если вы хотите сравнить Go и Rust для своего проекта, сделайте маленький, но честный тест

Правила:

• используйте реальный формат данных;
• измеряйте несколько запусков;
• фиксируйте версии компилятора и библиотек;
• запускайте на одной машине;
• проверяйте корректность результата;
• измеряйте не только среднее время, но и память;
• не оптимизируйте один вариант сильнее другого

Пример плана:

1. Взять один типичный входной файл
2. Написать минимальную обработку на Go
3. Написать минимальную обработку на Rust
4. Замерить время и память
5. Запустить профилировщик
6. Найти узкие места
7. Сделать одну оптимизацию в каждом варианте
8. Сравнить не только скорость, но и сложность кода

Последний пункт часто забывают. Если Rust быстрее на 15 процентов, но код в два раза сложнее для вашей команды, это может быть плохим обменом. Если Rust быстрее в три раза и снимает критичную проблему памяти, это уже другой разговор

Практический набор измерений

Для HTTP-сервиса можно начать с простого набора: hey, wrk или oha для нагрузки, системный мониторинг для CPU и памяти, логи приложения для ошибок и отдельная проверка базы данных. Важно запускать тест не один раз, а серией, чтобы увидеть стабильность результата

Минимальная схема выглядит так:

hey -z 60s -c 100 https://example.com/api/events

После нагрузки сохраните throughput, среднюю задержку, p95, p99, количество ошибок, потребление CPU и памяти. Если p99 плохой, не делайте сразу вывод про язык. Сначала проверьте базу, внешние вызовы, размер ответа, сериализацию, аллокации и блокировки

Для CLI или парсера полезнее измерять реальное время и память на одном и том же входном файле:

/usr/bin/time -l ./parser input.log

Сравнивайте не только секунды. Смотрите максимальную память, стабильность результата на нескольких запусках, сложность кода и то, насколько легко будет поддерживать реализацию через полгода

Когда разница не важна

Разница между Go и Rust по производительности часто не важна, если:

• проект небольшой;
• нагрузка умеренная;
• основная задержка в базе данных;
• важнее быстро менять бизнес-логику;
• команда лучше знает Go;
• нет жестких требований к памяти;
• сервис можно масштабировать горизонтально;
• bottleneck находится вне приложения

В таких случаях Go может быть более рациональным выбором. Вы быстрее сделаете продукт, быстрее исправите ошибки и проще подключите новых разработчиков

Когда разница важна

Разница становится важной, если:

• приложение работает с большими объемами данных;
• каждая миллисекунда задержки имеет значение;
• память ограничена;
• процесс должен работать долго и стабильно;
• нельзя мириться с GC-паузами;
• код близок к системному уровню;
• нужна библиотека с высокими гарантиями безопасности;
• нагрузку нельзя просто решить добавлением серверов

В этих сценариях Rust стоит рассматривать серьезно. Но даже здесь нужен прототип и измерения

Частые ошибки в сравнении производительности

Смотреть только на синтетические тесты

Синтетические тесты полезны, но они редко повторяют ваш проект. Реальный сервис упирается в сеть, базу данных, сериализацию, очереди, файловую систему и ошибки конфигурации

Сравнивать неоптимальный Go с оптимизированным Rust

Такой тест нечестен. Нужно либо писать оба варианта простыми, либо оба оптимизировать одинаково внимательно

Игнорировать поддержку

Производительный код, который команда боится менять, может стать проблемой. Скорость выполнения не должна полностью вытеснять скорость разработки

Не измерять память

Иногда программа быстрая, но потребляет слишком много памяти. Для контейнеров, serverless, embedded и плотной инфраструктуры это критично

Практический вывод

Для большинства backend-задач Go даст достаточно производительности и выиграет простотой. Для задач с жесткими требованиями к памяти, задержкам, системному контролю и надежности Rust может дать серьезное преимущество

Если сомневаетесь, не спорьте абстрактно. Возьмите самый тяжелый сценарий вашего проекта и измерьте. Если разница мала, выбирайте язык, который проще поддерживать. Если разница большая и влияет на бизнес или инфраструктуру, выбирайте язык, который решает это узкое место

Пример плана нагрузочного теста

Допустим, вы выбираете язык для сервиса, который принимает события и записывает их в хранилище. Не нужно сразу писать весь сервис дважды. Сделайте тестовый сценарий:

1. Endpoint принимает JSON-событие
2. Сервис проверяет обязательные поля
3. Сервис сериализует событие во внутренний формат
4. Сервис кладет событие в очередь или имитирует запись
5. Ответ возвращается клиенту

Для Go и Rust сделайте одинаковую минимальную реализацию. Затем запустите одинаковую нагрузку. Измерьте количество успешных запросов, среднюю задержку, p95, p99, память и CPU. Если есть ошибки, фиксируйте не только число ошибок, но и причину

Важно не делать тест слишком искусственным. Если в реальном проекте будет JSON, используйте JSON. Если будет protobuf, используйте protobuf. Если будет база, хотя бы имитируйте задержку записи или подключите тестовую базу. Иначе вы сравните не проект, а игрушечную функцию

После первого замера не спешите с выводами. Посмотрите профилировщик. Возможно, один вариант создает слишком много временных объектов. Возможно, второй тратит время на логирование. Возможно, узкое место вообще в тестовом клиенте, а не в сервисе

Как читать результаты

Представим, что Rust оказался быстрее на 20 процентов, но код сложнее, а команда почти не знает Rust. Это не автоматическая победа Rust. Нужно понять, что значит 20 процентов для проекта. Если сервис и так выдерживает нагрузку с запасом, проще выбрать Go. Если эти 20 процентов экономят десятки серверов или снимают критичный риск, Rust может быть оправдан

Другой вариант: Go и Rust дают похожий throughput, но у Go выше p99. Если проект чувствителен к хвостам задержек, это важно. Если это внутренняя batch-система, где p99 не критичен, разница может не иметь значения

Третий вариант: Go быстрее в разработке, Rust экономит память. Если сервисов будет много и они живут в ограниченных контейнерах, память может быть серьезным аргументом. Если сервис один и памяти достаточно, простота Go может быть важнее

Никогда не смотрите только на одно число. Хорошее сравнение включает скорость, память, стабильность, сложность кода, скорость разработки и стоимость поддержки

Профилирование в Go

В Go есть сильные встроенные инструменты профилирования. Через pprof можно смотреть CPU, память, goroutine, блокировки и другие показатели. Это часто позволяет оптимизировать сервис без смены языка

Типичный порядок такой:

1. Запустить нагрузку
2. Снять CPU profile
3. Посмотреть, какие функции занимают больше всего времени
4. Снять memory profile
5. Найти лишние аллокации
6. Исправить один узкий участок
7. Повторить тест

Частые проблемы в Go-проектах: лишняя сериализация, создание новых буферов на каждый запрос, неудачная работа со строками, слишком много goroutine без контроля, неоптимальные SQL-запросы. Все это можно улучшать точечно

Перед разговором «надо переписывать на Rust» стоит пройти хотя бы один нормальный цикл профилирования. Иногда после него Go-сервис становится в два раза быстрее без смены языка

Профилирование в Rust

В Rust тоже важно профилировать. Строгий язык не отменяет алгоритмических ошибок, лишних копий и неудачных структур данных. Можно написать Rust-код, который постоянно клонирует строки, создает лишние векторы или блокируется в неправильных местах

Что проверять:

• где происходят аллокации;
• не клонируются ли большие данные без необходимости;
• не используется ли слишком тяжелая структура данных;
• нет ли блокировок в горячем пути;
• правильно ли выбран async runtime;
• нет ли лишнего преобразования форматов

Оптимизация Rust часто требует большей внимательности, но и дает больше контроля. Если вы нашли горячий участок, можно точнее управлять памятью, буферами и lifetime данных

Пример решения: оставаться на Go

Представим сервис на Go, который обрабатывает 2000 запросов в секунду. Команда переживает, что Rust мог бы быть быстрее. После профилирования выясняется, что 70 процентов времени уходит на запрос к базе, а еще 20 процентов — на внешний API. Код приложения занимает небольшую часть времени

В такой ситуации переход на Rust почти не поможет. Гораздо полезнее:

• добавить кеш;
• оптимизировать SQL;
• уменьшить количество внешних запросов;
• настроить пул соединений;
• вынести тяжелые операции в очередь;
• улучшить индексы

Это типичная история. Язык приложения кажется главным фактором, пока вы не измерили систему целиком

Пример решения: выбрать Rust

Другой сценарий: сервис читает бинарный поток, разбирает миллионы сообщений в минуту, почти не ходит в сеть и базу, а основная работа происходит внутри процесса. Профилирование показывает много аллокаций, высокую нагрузку на CPU и чувствительность к задержкам

Здесь Rust может дать реальное преимущество. Он позволит точнее работать с буферами, избегать лишних копий, контролировать lifetime данных и убрать GC-фактор. Если команда готова к Rust, выбор может быть оправдан

Но даже в этом случае нужен прототип. Не переписывайте весь сервис сразу. Возьмите горячий участок, реализуйте его на Rust, измерьте и только потом решайте, нужен ли полный переход или достаточно отдельного компонента

Контрольный список перед выбором по производительности

Перед тем как сказать «берем Rust ради скорости» или «Go достаточно», пройдитесь по списку:

• есть ли реальные метрики нагрузки;
• известен ли bottleneck;
• измерены ли p95 и p99;
• понятно ли потребление памяти;
• проверено ли поведение под длительной нагрузкой;
• сравнивались ли одинаковые сценарии;
• учитывалась ли сложность поддержки;
• есть ли опыт команды;
• ясно ли, что делать, если нагрузка вырастет в 10 раз

Если на половину вопросов ответа нет, выбор пока преждевременный. Сначала измерения, потом язык

Как оптимизировать до смены языка

Перед переписыванием сервиса попробуйте базовые оптимизации. Они часто дают больше, чем смена Go на Rust или Rust на Go

Начните с базы данных. Проверьте индексы, количество запросов, повторяющиеся чтения, размер ответа и лишние поля. Один плохой SQL-запрос может съедать больше времени, чем вся логика приложения

Потом проверьте сериализацию. JSON удобен, но может быть тяжелым на больших объемах. Иногда помогает уменьшить структуру ответа, убрать лишние поля, кешировать готовый результат или перейти на другой формат для внутренних сервисов

Затем проверьте аллокации. В Go это можно смотреть через профили памяти. В Rust — через профилировщики и анализ мест, где создаются новые значения. Лишнее копирование строк, массивов и буферов часто незаметно в коде, но хорошо видно в измерениях

Потом проверьте архитектуру. Возможно, синхронная операция должна стать фоновой задачей. Возможно, внешний API нужно вызывать реже. Возможно, часть данных можно считать заранее. Такие решения не зависят от языка и часто дают главный выигрыш

Только после этого честно спрашивайте: «Язык все еще является проблемой?» Если да, можно рассматривать Rust ради контроля или Go ради упрощения. Если нет, переписывание будет дорогой иллюзией оптимизации

Мини-экзамен по производительности

Попробуйте ответить без подсказок:

1. Чем throughput отличается от latency?
2. Почему p99 может быть важнее среднего значения?
3. Когда GC Go может стать фактором?
4. Почему Rust не гарантирует автоматическую скорость?
5. Как понять, что узкое место в базе данных?
6. Почему один синтетический тест не доказывает выбор языка?
7. Когда память важнее скорости CPU?
8. Почему сложность поддержки тоже часть производительности проекта?

Если ответы получаются конкретными, вы готовы сравнивать языки инженерно. Если ответы расплывчатые, сначала разберитесь с метриками и профилированием. Без этого разговор о производительности легко превращается в спор по впечатлениям

Финальная рекомендация по скорости

Не начинайте с переписывания на другой язык. Начинайте с измерений. Если Go-сервис медленный, это еще не значит, что нужен Rust. Если Rust-код сложный, это еще не значит, что нужно отказаться от Rust. Сначала найдите место, где теряются время, память или стабильность

Правильная последовательность такая: метрики, профилировка, точечная оптимизация, повторный замер, только потом архитектурное решение. Если после этого язык остается главным ограничением, выбор будет обоснованным. Если нет, вы сэкономите недели или месяцы работы

Особенно осторожно относитесь к фразе «нам нужна максимальная производительность». Максимальная относительно чего? Относительно одного запроса, стоимости сервера, задержки для пользователя, скорости batch-обработки или потребления памяти? Пока это не уточнено, нельзя честно решить, нужен Go, Rust или просто нормальная оптимизация текущей системы

Быстрая проверка метрик

Запишите целевую метрику в числах: например, p99 ниже 50 мс, обработка файла быстрее 2 минут или потребление памяти меньше 128 МБ. Без такой цифры разговор о производительности остается слишком общим. После этого сделайте один небольшой тест на реальных данных и сравните результат с целью, а не с абстрактным ожиданием

Часто задаваемые вопросы

Что быстрее: Go или Rust?

В низкоуровневых задачах Rust часто может быть быстрее, но в обычном backend разница может быть неважной. Нужно измерять конкретный сценарий

Go медленный из-за сборщика мусора?

Нет. Go достаточно быстрый для огромного числа production-сервисов. GC может быть фактором в задачах с жесткими задержками, но не делает язык медленным автоматически

Rust всегда лучше для highload?

Нет. Highload часто упирается в архитектуру, базу данных, кеши, сеть и очереди. Rust полезен, когда реальное узкое место связано с памятью, CPU или задержками внутри приложения

Стоит ли переписывать сервис с Go на Rust ради скорости?

Только после профилирования. Сначала найдите узкое место. Возможно, достаточно исправить запросы, кеширование, аллокации или архитектуру

Какой язык выбрать для нового высоконагруженного сервиса?

Если команда сильнее в Go и требования обычные для backend, начните с Go. Если есть жесткие ограничения по памяти, задержкам или системному контролю, сделайте прототип на Rust и сравните

Следующий шаг

Возьмите один реальный сценарий из проекта: HTTP endpoint, обработку файла, воркер очереди или CLI-команду. Опишите метрики успеха: время, память, p95, p99, CPU. Только после этого сравнивайте Go и Rust. Так выбор будет инженерным, а не эмоциональным