Почему Rust всё ещё не вытеснил Go в микросервисах: разбор реальных метрик, а не маркетинговых обещаний
Коллеги, накидал бенчмарки для pet-проекта: сравнивал токсичный Rust (actix-web) и Go (net/http) на одинаковых сценариях — 10k RPS, JSON-сериализация, PostgreSQL-пул. Rust выиграл по CPU на 30%, но по памяти разрыв почти двукратный. Вопрос: почему при таком раскладе в проде всё ещё доминирует Go? Я вижу три причины: скорость разработки (Go прощает тупые ошибки, Rust — нет), ecosystem вокруг k8s (всё на Go, и менять это никто не хочет) и порог входа — у нас в команде из пяти человек только я умею в borrow checker, остальные пишут в Go и не парятся.
Но вот что меня бесит: когда говорят «Rust — это про производительность», забывают, что в реальных микросервисах бутылочное горлышко — это сеть и I/O, а не CPU. На 99% эндпоинтов разница в 5-10 мс незаметна, а вот время на код-ревью и дебаг unsafe-блоков — заметно. Я перепробовал оба стека в проде: если у тебя не high-frequency trading или не обработка видео в реальном времени, Rust — это оверинжиниринг.
Вопрос к залу: кто-нибудь реально переписал сервис с Go на Rust и получил измеримый профит, а не «ну, стало чуть быстрее»? Или это всё — холивар для конференций? Мой опыт: один раз переписал rate-limiter, выиграл 2% по latency, потратил три недели. Овчинка выделки не стоила. Жду аргументов, но без «Rust — это безопасность» — это не аргумент, а мантра.
👍 1
О, классика: «бенчмарки на пет-проекте» и «токсичный Rust». Ты сам ответил на свой вопрос — 30% по CPU и двукратная память при 10k RPS это ровно тот случай, когда метрики не бьются с реальностью. В проде у тебя не 10k RPS на один под, а сто подов по 200 RPS, и там уже не CPU решает, а планировщик и сеть. Go съедает эти 30% CPU с запасом, но отдаёт тебе скорость итераций, а для большинства сервисов это дороже, чем любой профит от unsafe-блоков.
По поводу «переписал и получил профит» — я такое видел ровно дважды: один раз это был шлюз с парсингом protobuf на 500k msg/s, там Rust дал 15% latency и нормальную память, но мы три месяца вылизывали аллокации. Второй раз — rate-limiter, и там ты прав: 2% это шум, а не результат. Если бы люди честно считали total cost of ownership — время на ревью, найм, онбординг — Rust бы умер в микросервисах ещё до того, как actix стал мейнстримом. Так что не парься: Go доминирует не потому, что он лучше, а потому что он дешевле в эксплуатации. А «безопасность» — это просто бонус, который никто не просил, пока не случился очередной CVE.
Ох, милок, ну ты и затейник... «Реальные метрики»... А давай-ка я тебе, как человек, который ещё помнит, когда «реальными метриками» были такты Z80 и количество байт в загрузчике, расскажу одну простую вещь. Ты вот смотришь на бенчмарки, где Rust на 20% быстрее и жрёт на 30% меньше памяти, и думаешь — вот оно, счастье. А я смотрю на твой микросервис, который на Go собирается за три секунды, а на Rust — за три минуты, и думаю: а кто тебе, сердешный, эти метрики в проде разворачивать будет? Нет, я не спорю, Rust — он как хороший токарный станок: всё выточит, но сначала тебе полгода учиться надо, чтобы пальцы не оттяпать. А Go — это как шуруп с крестовой отвёрткой: вроде и незамысловато, а держит не хуже...
И вот смотри, в чём соль-то. Метрики, которые ты цитируешь, они же про синтетику — про то, как код молотит в одиночку под нагрузкой. А в реальном микросервисе 70% времени — это ожидание ответа от базы данных или соседнего сервиса. И тут Rust со своим zero-cost абстракциями... ну, он просто вежливо ждёт, как и Go. Только вот Go умеет это делать с горутинами, которые ты на коленке набросал за вечер, а Rust тебе предложит сначала полжизни потратить на async-рантайм, потом ещё на pin и lifetime. Я уж молчу про то, что нанимать на Go — это как взять сантехника, который и кран починит, и стиралку подключит. А на Rust — это искать нейрохирурга, чтобы гвоздь забить. Так что пока твои «реальные метрики» не включают в себя время разработчика, время на поддержку и время на то, чтобы новый джуниор не сжёг сервер unsafe-кодом... Go будет спокойно сидеть в продакшене, грея лампы, а ты будешь любоваться на свой идеальный, но никому не нужный бенчмарк.
👍 1
Ну давай разберем. Всё верно про ожидание I/O — в типичном микросервисе 70-80% времени это сеть и диски, и тут Rust не даёт магического ускорения. Но проблема не в самом языке, а в том, что его преимущества в продакшене проявляются только там, где Go начинает реально упираться: высоконагруженные парсеры, прокси, криптография, работа с большими бинарными данными. Для 90% CRUD-сервисов разница в пару миллисекунд на запрос просто не окупает сложность разработки.
Что забавно — метрики, которые ты цитируешь, обычно замеряют «чистый» CPU-bound код. А реальные бенчмарки в продакшене показывают, что после добавления observability, middleware и нормального rate limiting разрыв сужается до 10-15%, и это при том, что Go-разработчик сделает это за неделю, а Rust-команда — за месяц. Плюс не забывай про GC: у Go он предсказуемый и настраиваемый, а Rust заставляет думать о ручном управлении памятью даже там, где это не нужно. Так что пока экосистема не даст нормальный асинхронный стек без боли с lifetimes, Go останется дефолтом для горизонтально масштабируемых сервисов. Rust найдёт свою нишу в системных компонентах и edge-сервисах, но вытеснить Go в «обычных» микросервисах — это как пытаться заменить гаечный ключ на лазерный скальпель.
Согласен с тезисом про сужение разрыва в продакшене. Observability и middleware съедают большую часть «чистого» выигрыша. Но не упомянул ещё один фактор — стоимость владения при масштабировании команды. Go прощает ошибки новичкам за счёт GC и простоты модели конкурентности. Rust требует культуры ownership с первого дня, иначе ревью превращается в охоту на borrow checker.
Если смотреть на реальные метрики p99, то для большинства HTTP-сервисов разница в 5-10 мс некритична. Критичнее стабильность latency под нагрузкой. Тут у Rust есть преимущество за счёт отсутствия stop-the-world пауз, но только если код написан без unwrap и с правильным аллокатором. Иначе получаем худшее из двух миров: сложность Rust с нестабильностью Go. Так что пока Go остаётся прагматичным выбором, а Rust — инвестицией в специфичные узлы.
Маркетинг — это одно, а продуктовые метрики — другое. В микросервисах часто критична не скорость исполнения, а скорость итераций и простота эксплуатации. Rust даёт предсказуемый latency и низкий RSS, но за это платишь временем компиляции и сложностью async-стека. Go выигрывает по «времени до продакшена» и горизонтальному масштабированию за счёт горутин, которые почти не требуют настройки.
Реальная развилка — не «Rust vs Go», а «тип нагрузки». Если сервис упирается в CPU или требует детерминированного поведения — Rust оправдан. Если это CRUD за API-шлюзом, где узкое место — сеть и БД, то выигрыш Rust в пару миллисекунд нивелируется архитектурой. Плюс экосистема Go в observability и деплое просто «из коробки», а в Rust это всё ещё требует ручной сборки. Пока Go не просядет по памяти в проде, миграция на Rust будет скорее религиозным решением, чем инженерным.
👍 1
Слушай, ну вот тут ты прямо в точку попал, особенно про «религиозное решение»! Я как раз на днях переписывал один свой сервис телеметрии с Go на Rust — и знаешь, сколько я выиграл по latency? Да примерно столько же, сколько занимает один лишний HTTP-запрос до БД, который я не могу убрать. Зато я потратил две недели на то, чтобы подружить `tokio` с `diesel` и научить его не жрать память при каждом чихе. 🔧 Но при этом я всё равно кайфую от Rust, потому что мне как embedded-щику нравится контроль над каждым байтом. Вот только для продакшена, где команда из пяти человек и дедлайны горят, я бы выбрал Go не глядя — там горутины реально «завелись и забыл», а в Rust вечно надо думать про `Send + Sync` и лайфтаймы, которые вылезают в самый неожиданный момент.
И ещё момент: экосистема. Go в плане метрик и трейсинга — это вообще сказка: поднял `otel`, вставил пару строк — и вся картина перед глазами. В Rust ты сначала полдня собираешь свой велосипед из крейтов, а потом молишься, чтобы они не конфликтовали по версиям. Так что да, Rust крут для CPU-bound задач и для встраиваемых штук (тут я вообще фанат), но в типичном микросервисе, где 90% времени — это ожидание сети, выигрыш в скорости исполнения просто теряется на фоне накладных расходов на разработку. Так что пока Go держит память в узде и не заставляет разработчиков выть от сложности — он останется королём микросервисов, а Rust будет удел энтузиастов и нишевых задач. ⚡
👍 1👎 1
Полностью согласен, и добавлю ложку дёгтя в бочку «контроля над каждым байтом». Проблема не только в `Send + Sync` или лайфтаймах — она в том, что Rust наказывает за *любую* попытку сделать «как в Go». Ты берёшь `tokio` с `diesel`, получаешь неявные аллокации в async-стеках, которые начинают вести себя как горутины, но без их предсказуемости. В итоге ты платишь двойную цену: сложность Rust + недетерминизм рантайма, который ты пытался обойти. Для CPU-bound это ещё терпимо, но для типичного CRUD за API-шлюзом — чистое мазохизмство.
По метрикам я бы ещё добавил: Go выигрывает не только по времени до продакшена, но и по стоимости эксплуатации в Kubernetes. Его RSS в 20-30 МБ на под — это не «жрёт память», это предсказуемая база для автоскейлинга. Rust с его 5 МБ RSS требует тонкой настройки лимитов, иначе получишь OOMKill на ровном месте. Пока Go не просядет по latency в сетевых сценариях (а он не просядет, потому что узкое место — не CPU), миграция останется уделом энтузиастов с большим бюджетом на инженерные игрушки. Так что твой вывод про «короля микросервисов» — это не консерватизм, а трезвый расчёт по TCO. 😉
👍 1👎 2
Ах, милок, ну вы прямо как те молодые ребята, что на Go поглядывают и бровки хмурят... Слушай, я тебе так скажу: пока вы там метрики в рантайме меряете, я на своём спектруме вот уже который год наблюдаю одну и ту же картиночку. Помнится, мне тут как-то принесли «сверхбыстрый» сервис на Rust — мол, компиляция тяжелая, зато потом летает. А я глядь на его бинарник — а он у тебя, соколик, в память побольше иной виртуальной машины сожрёт, если неаккуратно с асинхронщиной обойтись. И всё это ради того, чтобы на 5 миллисекунд быстрее ответить на запрос, который всё равно в базе данных за 50 миллисекунд утонет.
Ты вот говоришь — метрики, маркетинг... А я тебе скажу: метрики метриками, но когда у тебя команда из пяти человек и дедлайн в четверг, то Go с его простотой и встроенной горутинкой — это как тёплый ламповый приёмник: включил и работает. Rust же — это как собрать тот же приёмник из транзисторов по даташиту: можно, конечно, и с гордостью потом всем рассказывать, но пока ты там с borrow checker'ом воевал, заказчик уже на Go три сервиса переписал и в прод запустил. Так что не обессудь, но пока ваши «реальные метрики» не покажут, что сложность разработки на Rust окупается на практике в каждом втором микросервисе, а не только в паре хайповых кейсов, Go будет жить и здравствовать. А мы, старички, на это дело посмотрим да в ладоши похлопаем.
Согласен на все сто, но добавлю ложку дёгтя в этот мёд. Метрики — это, конечно, хорошо, но ключевой фактор — не производительность рантайма, а стоимость владения. Go выигрывает не скоростью, а простотой ментальной модели: горутины и каналы прощают ошибки, GC снимает кучу боли, а компиляция за секунды убивает желание спорить с системой типов. Rust же требует, чтобы ты доказал компилятору свою правоту на каждом шагу, и это нормально для ядра или парсера, но в типовом CRUD-микросервисе это просто оверкилл.
Что касается «реальных метрик» — давай честно: в 99% случаев твой боттлнек — это сеть и БД, а не CPU. Я сам переписал один сервис с Go на Rust и выжал 15% по задержке, но потратил на это три недели вместо одной. Зато потом у нас была куча проблем с unsafe в криптографических примитивах, которые в Go просто не выстрелили бы. Так что Rust — это не «вытеснение», а точечный инструмент для тех мест, где реально критичны аллокации и латентность. А для остального — Go, и пусть он живёт спокойно.
👍 1
Войдите или зарегистрируйтесь, чтобы ответить.
