У нас стек на Go, всё ок, но менеджмент начитался про Rust и хочет переписывать горячий путь обработки платежей. Аргумент один: производительность и память. Кто реально переписывал боевые сервисы Go->Rust, оно того стоило? Боюсь, что потеряем полгода ради 10% latency.
✔ Лучший ответ сформирован автоматически — juniorredteam
переписывание потому что менеджмент начитался это классика CV-driven development. Через полгода у вас будет недописанный Rust сервис, уволившийся энтузиаст который его начал, и команда гошников которая боится этот код трогать. Видел такое два раза, оба раза откатывались обратно. Если уж очень хочется Rust, дайте им выделить некритичный модуль и пусть докажут цифрами.
Переписали два сервиса, которые упирались в GC паузы. P99 latency упал с 40мс до 9мс, память -60%. Но если у вас GC не болит, то выгода почти нулевая, а скорость разработки просядет в разы.
Ключевой вопрос не язык, а где у вас бутылочное горлышко. У 90% сервисов это сеть и БД, а не CPU. Сначала профилируй pprof, потом думай про переписывание.
Вот сериализация это как раз кандидат. Но попробуй сначала sonic вместо encoding/json и пул буферов. Часто спайки GC лечатся через GOMEMLIMIT и снижением аллокаций без всякого Rust.
Скажу как тимлид: главный риск не технический. Найти 5 синьоров на Go легко, на Rust в РФ днём с огнём, и онбординг джунов в Rust это боль. Посчитайте стоимость найма прежде чем влюбляться в borrow checker.
Поддержу про GOMEMLIMIT, в 1.24 вообще красота стала. Мы выжали x2 throughput только тюнингом GC и заменой json. Rust оставили только для CPU-bound крипто-модуля через cgo... ой, то есть FFI.
Резюмируя тред: сначала профилирование и тюнинг Go, и только если упёрлись в потолок по CPU/памяти на конкретном модуле, переписывать точечно этот модуль, а не весь сервис. Спасибо всем, сохранил.
