У Rust давно репутация языка, который покупает скорость ценой боли для команды. На практике у Momento вышло иначе: компания, строящая сервисы кэширования, после перехода на Rust получила не только высокую производительность, но и более короткий цикл разработки. Для русскоязычной IT-аудитории это важный сигнал: переход на Rust может оказаться не экзотикой для системщиков, а вполне прагматичным решением для backend-команд, которые живут под давлением latency, нагрузки и ошибок в проде.
Об этом на QCon San Francisco рассказала старший инженер Momento Рут Лайнхэн, сообщает InfoQ. По ее словам, внутри компании изначально смотрели на Rust почти по учебнику: да, код будет быстрее, но инженерные затраты вырастут в разы, а скорость поставки фич просядет. За три года миграции картина оказалась сложнее. Momento начинала с Kotlin-сервисов, а затем постепенно перевела на Rust сначала самые чувствительные к производительности компоненты, а позже и самый сложный workflow-сервер, который сама докладчица прямо называет не системным и не особенно performance-sensitive. Иными словами, переход на Rust вышел за рамки чистой оптимизации горячих путей.
Цифры, которыми оперирует Momento, объясняют, почему тема вообще дошла до уровня архитектурной стратегии. Компания ежедневно гоняет performance-тесты: около 60 тысяч транзакций в секунду при задержке 3 мс на 99,9-м перцентиле на достаточно крупных инстансах. Дальше эти же инстансы, а иногда и более крупные, добивают до примерно 600 тысяч транзакций в секунду и выше. Для стартапа это не красивый слайд, а вопрос экономики инфраструктуры: сколько трафика можно упаковать в один узел, сколько стоит каждая единица нагрузки и где именно язык начинает влиять на бюджет не хуже, чем архитектура или выбор облака. В таком контексте переход на Rust перестает быть разговором про вкусы команды и становится разговором про операционную эффективность.
Но самое интересное в выступлении Лайнхэн не TPS и не latency, а спор с популярным тезисом о медленной разработке на Rust. Она не отрицает, что порог входа высокий. Наоборот, прямо говорит: если нужно быстро набросать proof of concept или одноразовый прототип, Rust, скорее всего, не лучший выбор. Ее тезис другой: для production-кода первоначальная медлительность окупается более ранней и более качественной обратной связью. Чем раньше разработчик узнает, что сломал контракт владения, жизненный цикл данных или конкурентный доступ, тем меньше времени уходит на прогон через dev-окружения, ручную проверку, переключение контекста и последующий отлов дефектов уже после релиза. В этом месте разговор о языке внезапно становится разговором о стоимости фидбэк-лупа.
Ключевой аргумент доклада построен вокруг ergonomics, хотя слово «эргономика» рядом с Rust обычно звучит как шутка. Лайнхэн разбирает типичную для новичка ситуацию: разработчик хочет просто вывести значение переменной в лог и получает массивное сообщение компилятора про borrow of moved value. Формально это тот самый момент, из-за которого Rust считают враждебным. Но ее вывод обратный: если не отмахиваться от ошибки, а читать подсказки компилятора и расширенные объяснения, язык не просто ругается, а предлагает варианты исправления. Например, передать ссылку вместо владения или, если цена приемлема, сделать clone. Для команды это означает, что значимая часть проблем ловится в момент написания кода, а не после запуска интеграционных тестов, не на ревью и точно не после инцидента в проде.
В докладе звучит еще одна деталь, которая особенно близка тимлидам и engineering-менеджерам: уверенность разработчика в корректности кода сама по себе ускоряет поставку. Лайнхэн ссылается на внутренний опрос Google за 2022 год, где 85% респондентов заявили, что уверены в корректности своего Rust-кода. Это не академическая метрика и не абсолютная истина, но направление мысли понятно. Если инженер меньше гадает, не всплывет ли гонка, use-after-free или поломанный state transition в соседнем потоке, он тратит меньше времени на защитное программирование и бесконечную проверку очевидного. На масштабе сервиса это влияет не только на скорость написания кода, но и на качество эксплуатации.
Отдельный слой истории Momento связан с инструментами вокруг языка. Лайнхэн упоминает Criterion и flamegraphs как рабочие инструменты для оптимизации конкурентных участков кода. Это важный практический штрих: переход на Rust сам по себе не превращает сервис в ракету, если команда не умеет измерять поведение системы и находить реальные узкие места. В индустрии нередко продают язык как серебряную пулю, а потом выясняется, что bottleneck сидел в сетевом протоколе, конфигурации рантайма или архитектуре очередей. В кейсе Momento акцент смещен в правильную сторону: Rust дает более строгие гарантии и хороший фундамент, но производительность добирается профилированием, бенчмарками и дисциплиной в работе с concurrency.
Для российского рынка разработки из этой истории есть несколько приземленных выводов. Во-первых, переход на Rust имеет смысл рассматривать там, где команда уже уперлась в стоимость latency, плотность нагрузки или сложность конкурентного кода. Во-вторых, язык может быть оправдан не только для сетевых движков, брокеров сообщений и storage-слоя, но и для более «обычных» backend-сервисов, если их сложность настолько высока, что compile-time guarantees реально экономят время. В-третьих, миграция выглядит разумнее как последовательное смещение критичных сервисов, а не как идеологический крестовый поход против JVM или Kotlin. Momento именно так и шла: сначала производительность, потом унификация стека и использование преимуществ языка в сложной бизнес-логике.
При этом выступление Лайнхэн не стоит читать как агитацию в стиле «все переписываем на Rust к понедельнику». Она специально оговаривает, что не призывает бежать и срочно переписывать существующие системы. Смысл скорее в переоценке допущений. Если в компании Rust до сих пор лежит в папке «слишком дорого по людям и срокам», кейс Momento показывает, что это допущение не универсально. Переход на Rust может тормозить на старте, зато потом сокращать число дорогостоящих ошибок и убирать часть инженерной неопределенности, которая обычно и съедает сроки.
Главный вопрос теперь не в том, быстрее ли Rust как язык, а в том, где проходит граница его экономической целесообразности для конкретной команды. Чем дороже обходятся баги конкурентности, нестабильная latency и перерасход инфраструктуры, тем слабее звучит старый аргумент про «слишком медленную разработку». И тем чаще переход на Rust будет обсуждаться не как выбор энтузиастов, а как нормальный управленческий инструмент.