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

Немного контекста: У нас классический монолит на Java (Spring Boot), который неплохо служил нам лет 5. Но с ростом нагрузки до 100k+ RPS мы уперлись в лимиты:

  • Потребление памяти под 16-32 GB на инстанс

  • GC паузы по 200-300ms в пике

  • Стоимость облачной инфраструктуры стала сопоставима с зарплатой нескольких миддлов

И мы приняли решение — переписать самые горячие пути на что-то более эффективное. Кандидаты: Go, Rust и современный C++.

Go: модный и быстрый на старт

Плюсы:

  • Простота написания конкурентного кода (горутины — это действительно круто)

  • Быстрая компиляция

  • Отличная стандартная библиотека для сетевых задач

Минусы, с которыми столкнулись:

  • Сборка мусора всё ещё дает просадки, хоть и меньше чем в Java

  • Нет настоящей работы с памятью — в некоторых сценариях это критично

Вердикт: Идеально для быстрого старта, но не дает того контроля, который хочется в ядре системы.

Rust: хайп и реальность

Плюсы:

  • Нулевая стоимость абстракций — это не шутка

  • Гарантии безопасности памяти без GC

  • Невероятно умный компилятор

Минусы на практике:

  • Кривая обучения круче, чем кажется

  • Время компиляции в больших проектах измеряется минутами

  • Некоторые концепции (lifetimes) требуют переосмысления архитектуры

Вердикт: Мощно, но дорого в разработке и поддержке.

C++23: старый добрый друг с новыми трюками

Что удивило:

  • Модули наконец-то работают как надо

  • Coroutines в стандартной библиотеке

  • Концепты делают шаблоны читаемыми

  • Меньший оверхед по памяти чем у Go и Rust

Боль:

  • До сих пор нет нормальной системы пакетов (хотя vcpkg и Conan спасают)

  • Нужны очень опытные разработчики

Наш выбор и почему

После 3 месяцев прототипов и бенчмарков мы остановились на... Zig.

Шутка! Хотя Zig мы тоже смотрели — но для продакшена рано.

Реальный выбор — Rust. И вот почему:

  1. Долгосрочная выгода: Да, первые 2 месяца скорость разработки была ниже. Но потом — стабильный рост без дебаггинга багов с памятью и data races.

  2. Экосистема: Tokio + Hyper показали производительность лучше чем Go net/http и сравнимую с оптимизированным C++.

  3. Компиляция в WASM: Это оказалось killer feature! Мы можем компилировать отдельные модули в WASM и запускать их в разных средах.

Что в сухом остатке через 6 месяцев:

  • Потребление памяти: упало в 4-5 раз

  • Производительность: выросла в 2-3 раза

  • Количество багов: критических — почти ноль

  • Стоимость инфраструктуры: уменьшилась на 60%

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

А что выбираете вы для высоконагруженных сервисов в 2025? Делитесь в комментах!

P.S. Кто заинтересовался — в следующем посте распишу наш стек инструментов для Rust в продакшене: мониторинг, дебаггинг, деплой...

Комментарии (21)


  1. sedyh
    04.10.2025 05:56

    Почему третий пункт приписан, как killer-feature раста? Он, конечно, хорошо туда собирается, но плюсы и go тоже умеют в wasm. И у всех трех есть zerodep embedded рантаймы для запуска модулей по типу wasmi, wasm3, wazero.


  1. gmtd
    04.10.2025 05:56

    Автор зашел вчера на Хабр, запостил 4 сгенерённые LLM статьи, и... дальше что?


    1. shlmzl
      04.10.2025 05:56

      Если сгенерировал, то хотелось бы знать чем было сгенерировано вот это:

      Вот алгоритм, который позволит вам спать спокойно, используя GPT-5:

      1. Декомпозируйте задачу. Разбейте её на мелкие, атомарные части.

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

      3. Генерируйте код небольшими порциями. Не целый модуль, а одну функцию, один класс, один метод.

      4. Проверяйте ВСЁ. Линтеры, тесты, внимательный код-ревью. Никаких исключений.

      5. Рефакторите и интегрируйте. Вставьте проверенный код в свою кодобазу, приведите к своим стандартам.

      Очень неплохо на мой взгляд. Сам(а) GPT-5 дает советы как строить ракботу с ней (ним)?


  1. sunUnderShadow
    04.10.2025 05:56

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


  1. Dhwtj
    04.10.2025 05:56

    Автор провокатор и выдумщик.

    Вопросы:

    Кто же вам дал старый священный код переписывать? Да ещё и время команды тратить.

    "переписать самые горячие пути" - а интегрировать как? Есть много тонкостей.

    Почему такое неправдоподобно большое преимущество по памяти и ЦП перед старой системой? Где именно?

    Где цифры, Билли?!

    З.Ы. Крутая кривая обучения Раст это преувеличение. Просто забудьте всё, чему вас учили раньше©


  1. Smartor
    04.10.2025 05:56

    Хотелось бы увидеть какие-нибудь картинки с тестами, что ли. А то написать сейчас так можно про что угодно:)


    1. Rive
      04.10.2025 05:56

      В топе бенчмарков techempower стабильно фреймворки на Rust, C и C++, иногда NodeJS.

      Для разработки лучше может оказаться использовать не топ-3 фреймворки (поскольку они подгоняются под тесты соревнования), и в процессе вполне можно написать глубоко неоптимальный тормозной код, но некоторые языки просто удобнее для написания высокопроизводительного кода, чем другие (за счёт отказа от виртуальной машины, сборщика мусора и прочих вещей, которые облегчают жизнь разработчикам, но не потребителям).

      На задачах компании ТСа рейтинг языков и фреймворков может быть другой, разумеется (на скриншоте - просто RPS статичной страницы).


  1. Wicort
    04.10.2025 05:56

    У нас в компании Java (SpringBoot) пока всё равно остается на первом месте просто потому что вся экосистема на это завязана - генераторы кода и прочее - ну и компетенции разработчиков тоже. Однако, самые высоконагруженные сервисы потихоньку переезжают на Go. Лично меня это пока не коснулось, но в планы аттестаций MSA разрабов Go уже залетел как обязательный пункт.


  1. Jijiki
    04.10.2025 05:56

    в минусах С++ - специалист

    а типо на на расте и го не нужен специалист?


  1. ALapinskas
    04.10.2025 05:56

    Немного контекста: У нас классический монолит на Java (Spring Boot), который неплохо служил нам лет 5. Но с ростом нагрузки до 100k+ RPS мы уперлись в лимиты:

    Поднять еще нод, не вариант?


    1. denis_iii
      04.10.2025 05:56

      Судя, по 200-300ms пауз в пике, сервис наоборот надо было разрезать на более мелкие кучи и запустить с нормальным современным GC.


  1. NN1
    04.10.2025 05:56

    А почему не рассматривался C# ?

    Современный .NET позволяет даже работать напрямую с памятью с нулевым оверхедом.


  1. HaxeZ
    04.10.2025 05:56

    На самом деле хотелось бы увидеть примеров: контроллера, ORM и обращений в БД, легирования (желательно сквозного там c OTel и Jaeger), юнитов под это добро написанных и тд, DI особенно после Spring-экосистемы.

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

    UPD: дописал про DI


    1. Gorthauer87
      04.10.2025 05:56

      Вот кстати с логировагием и телеметрией есть tracing, он нас устраивал до определённого момента, но начал бесить своей не гибкостью и мы приняли решение на fastrace переезжать.


      1. HaxeZ
        04.10.2025 05:56

        Про fastrace не слышал, спасибо, запишем.


  1. akod67
    04.10.2025 05:56

    В нынешней реальности надо ещё анализировать качество перегонки кода туда сюда LLMками


  1. Gorthauer87
    04.10.2025 05:56

    Забавно, что мы со скалы на rust переписали сервис и примерно такие же порядки цифр по памяти и процессору получили. Ну и в результате там теперь 8 подов, а не 32.


  1. azgnetov
    04.10.2025 05:56

    Скорость работы это хорошо, а скорость стабильной работы сравнивали? А то вот убунтоводы тоже на ржавом переписали gnu coreutils и сразу начали огребать: https://www.phoronix.com/news/Ubuntu-25.10-Coreutils-Makeself


  1. gev
    04.10.2025 05:56

    Haskell не хватает в списке ;)


  1. Jijiki
    04.10.2025 05:56

    раст хороший язык, сейчас многие переходят на него наверное


  1. Fardeadok
    04.10.2025 05:56

    Открою секрет: на си еще быстрее будет) просто надо его не напрямую через хттп использовать