"Rewrite it in Rust" is the new "have you tried turning it off and on again."
Here's the thing: Rust probably won't make your service faster. Grab proved it.
Grab's Counter Service handles event streams, Scylla storage, and gRPC endpoints. Tens of thousands of requests per second.
They rewrote it from Go to Rust. Full rewrite, not a line-by-line translation.
The latency results? Go's P50 was 12ms. Rust's P50 was 11ms—basically the same. Go's P99 was 45ms. Rust's P99 was 48ms—actually worse.
Latency didn't improve at all. In some cases it got worse.
Here's where it gets interesting. To handle 1,000 requests per second, Go needed about 20 CPU cores. At cloud prices, that's roughly $2,000/month. Rust needed about 4.5 cores for the same throughput—around $600/month.
That's a 70% cost reduction. Same latency, fraction of the compute.
That's the real argument for Rust. Not speed. Efficiency.
Go is already fast for network services. The bottleneck is I/O—database calls, network hops.
Think about the lifecycle of a request. Parsing takes about 0.1ms—this is where language matters. The Scylla query takes 10ms—I/O bound. Serializing the response takes another 0.1ms—language matters here too. Network round-trip takes 5ms—I/O bound. Total: 15.2ms. The language only affects 0.2ms of that. About 1.3% of total request time.
Rust doesn't make your Scylla query faster. If you're I/O-bound, no language rewrite fixes latency.
CPU-bound workloads are where Rust wins: image and video processing, compression, cryptography, game engines. These are compute-heavy and Rust shines.
I/O-bound workloads don't care: web APIs, database queries, file operations, network calls. The language is waiting on something else most of the time.
Most backend services are I/O-bound. Rust won't help.
The rewrite wasn't free.
Go has a mature ecosystem. Internal libraries, config management, logging, tracing—all sorted. Team has five years of experience with the language.
Rust? Rebuild internal libraries from scratch. Find alternatives for config management. Evaluate logging and tracing options. Team has six months of Rust experience.
Borrow checker fights are real. Accidental blocking calls in async code cause subtle bugs. Every Go library they relied on needed a Rust equivalent—evaluated by GitHub stars and the hope it doesn't get abandoned next year.
Should you rewrite in Rust?
If you have high traffic with simple logic, yes. If you have complex business logic, probably not—the rewrite cost is too high. If infrastructure cost is a real problem you're actively solving, yes. If latency is the problem, no—fix your architecture instead. If your team already knows Rust, yes. If your team needs to learn Rust, probably not worth the investment.
Grab's Counter Service had high traffic, simple logic, and infrastructure costs that mattered. Good candidate.
Your CRUD API with 50 requests per second? Keep it in whatever language your team knows.
The fastest language is the one your team can ship and maintain.
— blanho
You have 10 million saved searches. A new item comes in. How do you find all matches without running 10 million queries?
High throughput doesn't mean low latency. Often it means the opposite.
Reddit moved their comments system from Python to Go. The unglamorous reality of migration.
