
Міграція з Go на Rust: що насправді змінюється для бекенд-команд
corrode.dev опублікував орієнтований на бекенд посібник із переходу сервісів з Go на Rust. Головна теза: питання не в швидкості Rust, а в гарантіях, які дає компілятор, і в тому, як змінюються поведінка в рантаймі та ергономіка розробника.
corrode.dev опублікував орієнтований на бекенд посібник із перенесення сервісів з Go на Rust. Його головна теза: для більшості команд питання не в тому, чи швидший Rust — Go вже достатньо швидкий для типових бекенд-навантажень — а в тому, які гарантії дає компілятор. Насправді змінюються гарантії коректності, поведінка в рантаймі та ергономіка розробника.
Що змінюється на практиці
Інструменти майже повністю збігаються: cargo build, run, fmt, test і doc роблять те саме, що відповідні команди Go. Головна зміна — у тому, де живуть перевірки. Обробка nil, поширення помилок, гонки даних і час життя ресурсів переходять із конвенцій у систему типів: Option і Result замінюють перевірки на nil та if err != nil, а спільний доступ до змінних даних між потоками вимагає типів Send і Sync. Звичайна хеш-таблиця, яку ділять потоки, просто не скомпілюється — її потрібно загорнути в тип із блокуванням або замінити каналом.
Чому команди розглядають перехід
Посібник перелічує болючі місця, які накопичуються в сервісах на Go: багатослівна обробка помилок, ризик паніки через nil-вказівник і межі детектора гонок — go test -race знаходить лише ті гонки, які реально виконуються під час тестів, тоді як зміна мапи без блокування компілюється й падає під навантаженням. Засновника й технічного директора InfluxData Пола Дікса цитують про те, що дала команді переписування InfluxDB з Go на Rust: «безстрашна конкурентність — фактично усунення гонок даних, які були в нас раніше. Через них у першій версії Influx були справді гидкі баги».
Перехід без переписування
Рекомендований шлях — поетапний, а не повне переписування: виокремити один гарячий шлях або фоновий процес за тим самим API-контрактом, або спрямувати окремі ендпоїнти на новий сервіс на Rust за допомогою патерну strangler за API-шлюзом. Починайте з сервісу з чіткими межами та невеликим радіусом ураження, зберігайте шляхи, структуру JSON і формат помилок незмінними, і не пишіть Rust у стилі Go — інтерфейси з одним методом зазвичай стають обмеженнями трейту на дженерику. Навчання має відбуватися заздалегідь і на реальному коді, застерігає посібник, адже час компіляції в Rust справді гірший, ніж у Go.
Що отримують команди і де лишається Go
Очікувані вигоди подано як приблизні цифри, а не обіцянки: споживання CPU менше на 20–40%, пам'ять — на 30–50%, p99-затримка стабільніша під навантаженням, а інцидентів у продакшені значно менше, бо класи багів, які переживають go test -race — гонки даних, розіменування nil, пропущені шляхи обробки помилок — у Rust просто не компілюються. Десятикратного зростання пропускної здатності ніхто не обіцяє. Так само чітко сказано, що має залишитися на Go: оператори й контролери Kubernetes, CLI та інструменти розробника, а також тонкі API та сервіси конвертації форматів. Віцепрезидента з інженерії Canonical Джона Сіґера цитують: Go залишається «дуже добрим вибором для мережевих сервісів». Багато команд приходить до поліглотного бекенду: Go для нудних сервісів, Rust — там, де надійність і продуктивність виправдовують додаткові зусилля.
SiTech — веброзробка з підтримкою AI
Створюємо швидкі та сучасні сайти й інтегруємо AI у бізнес-процеси. Маєте проєкт чи запитання? Із задоволенням допоможемо.