Rust is one of the most exciting languages of the last decade.
But excitement is not a good architectural decision criterion.
When Rust Wins Big
- Performance-critical infrastructure (databases, proxies, WASM runtimes)
- Systems where memory safety bugs are catastrophic (browsers, OS kernels)
- Long-lived, high-stakes services where correctness > development speed
- Crypto, embedded, or real-time systems with strict safety requirements
When Rust Is Usually a Poor Choice
- CRUD applications / typical web backends (latency is rarely the bottleneck)
- Teams without at least 2–3 experienced Rust developers
- Projects that need to ship MVP in weeks, not months
- Systems dominated by I/O wait, not CPU-bound computation
- When the ecosystem/tooling gap would slow the team more than C++/Go
The Real Trade-off Table
| Scenario | Best Default | Use Rust when... |
|---|---|---|
| Typical web API | Go / Node.js / Python FastAPI | You are already CPU-bound at scale |
| High-performance proxy/load balancer | — | Almost always Rust (or C++) |
| New team startup MVP | Whatever the team knows best | Only if the team already knows Rust |
| Long-term infrastructure | — | Strong candidate |
Rust is an incredible tool.
It just isn't the right tool for every job — and pretending it is usually costs more than it saves.
← Back to Thinking & Writings