How Grab’s Migration from Go to Rust Cut Costs by 70%
https://blog.bytebytego.com/p/how-grabs-migration-from-go-to-rust

tl;dr Основным языком был Go, потом переписали один важный сервис на Rust и снизили затраты на 70%.

Теперь не очень кратко

Был выбран высоконагруженный, но достаточно простой по функциональности сервис

> To approach this decision carefully, the Grab Engineering Team set clear criteria for selecting a service to rewrite. The chosen system needed to be simple enough in its functionality to avoid unnecessary complexity. It also had to serve large amounts of traffic so that any efficiency gains would be meaningful. Finally, the team needed to be confident that engineers were willing and able to learn Rust to support the system for the long term.

Таким сервисом стал Counter Service, который отслеживает происходящее и предоставляет различные счётчики

- Фиксирует события, считает их и складывает в ScyllaDB
- Отвечает на GRPC запросы, которые собственно и касаются "циферок"

> While Counter Service handles very high traffic, reaching tens of thousands of requests every second at peak times, the work it performs is straightforward. It counts, stores, and returns numbers.

На первой картинке видно как этот сервис организован

Переписывали сервис "вслепую", как "чёрный ящик". Новая реализация должна была повторять полностью ответы старой системы на одинаковые запросы.

Далее смотрели какие библиотеки есть для Rust, что бы во-первых упростить перенос, во-вторых оценить некую "зрелость" зависимостей.

Here are the main dependencies:

- Datadog StatsD client: The Grab engineering team chose Cadence. It had fewer than 500 GitHub stars, which suggested a smaller user base, but the API was intuitive and covered all the required features.

- OpenTelemetry: They used opentelemetry-rust, which had more than 1,000 stars and solid community backing.

- GRPC: The tonic library was selected, a well-known Rust implementation of GRPC with active use and more than 500 stars.

- Web server: actix-web was picked. It is one of the most popular Rust frameworks, with more than 20,000 stars.

- Redis: Initially, the team tried redis-rs, the “official” Redis client with over 3,000 stars. However, it did not meet the needs of the project’s asynchronous design. They switched to fred.rs, which had over 5,000 stars and better async support.

- Scylla: They used the scylla-rust-driver. Although it had only around 500 stars, it was officially maintained by the Scylla project, giving confidence in its long-term support.

- Kafka: The kafka-rust client, with over 1,000 stars, was adopted to handle messaging needs.

Следующей проблемой было то, что их собственные компоненты и либы были написаны на Go. Одну из таких важных библиотек им пришлось переписать на Rust.

Пост большой и дальше там поднимаются проблемы Borrow Checker'а (а кто с ним не боролся на первых шагах 🌝) и Async Concurrency (тоже ловили проблемы на первых этапах разработки).

Итого
- Сервис перепилили
- latency обе реализации показали приблизительно одинаковую, иногда у Rust даже медленнее (вторая картинка)
- Но для реализации на Rust ресурсов надо меньше:

- The Go service needed about 20 CPU cores.
- The Rust service needed only about 4.5 cores.
- This translated into nearly five times better efficiency and about 70 percent lower infrastructure cost for the same workload.

Основных три общих вывода

- Rust is not always faster than Go. Go is already fast enough for most high-performance services, so Rust will not necessarily reduce latency

- Rust is more efficient. Thanks to its design, Rust uses less computing power to achieve the same results. This makes it especially valuable for services with heavy traffic where cost savings add up quickly

- Rust’s learning curve depends on context. Writing synchronous code in Rust is manageable for most experienced developers, especially with the help of the compiler and the Clippy linter. The real challenge comes with asynchronous code, which requires a deeper understanding of concurrency