Rust has stopped being a niche systems language. The web ecosystem — Axum, Tokio, sqlx, serde — has matured to the point where you can build a real HTTP service without spelunking through unsafe blocks or fighting async ergonomics. The question every TypeScript-heavy team eventually asks: is it actually worth the switch for any of our services?
Where Rust unambiguously wins
- Hot-path image, video, or document processing where Node's single-threaded model becomes the bottleneck.
- Long-running services that previously suffered from memory leaks or unpredictable GC pauses.
- Anything CPU-bound at scale — parsing, encryption, ML inference glue, large-graph traversal.
- Edge compute where binary size and cold-start time matter and Node simply can't compete.
Where it isn't worth the rewrite
- Standard CRUD APIs that are I/O-bound. The latency difference vs. Node is measurable but small, and you've thrown away your team's productivity.
- Anything that needs to ship a feature this week. Rust's iteration speed for greenfield code is real but never as fast as TypeScript's.
- Services that interface heavily with libraries that only exist in JS-land. The FFI overhead eats your wins.
The learning curve, honestly
It took our senior TypeScript engineers about three weeks to write Rust they weren't ashamed of, and another six weeks to write Rust they actually liked. The borrow checker is the tax everyone warns you about — it's real, but it teaches you things about ownership that quietly improve your TypeScript afterwards.
Async Rust is harder than sync Rust by a wide margin. Pin, Send, Sync, and lifetimes-in-async-blocks compose into a steep cliff. Plan for it.
Our policy now
We default to TypeScript for everything customer-facing and reach for Rust deliberately when we see CPU-bound work or strict latency budgets. We've yet to regret a single Rust rewrite — and we've also explicitly killed two proposed Rust rewrites because the math didn't justify them. Both decisions are equally important.