Назад

Міграція з Go на Rust: що насправді змінюється для бекенд-команд
SiTech AI Team3 хв читання

Міграція з 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

SiTech — веброзробка з підтримкою AI

Створюємо швидкі та сучасні сайти й інтегруємо AI у бізнес-процеси. Маєте проєкт чи запитання? Із задоволенням допоможемо.