A fresh discussion — see Simon Willison’s note — has reignited the perennial “rewrite it in Rust” debate for JavaScript runtimes like Bun. Here’s a pragmatic take for engineering leaders and runtime hackers.
Below is a short framework to decide if (and where) Rust makes sense — plus ways to de-risk the work and measure real wins before committing.
Why “rewrite in Rust” gets attention
Rust offers memory safety without a garbage collector and C/C++-class performance. That’s appealing for runtimes juggling tight event loops, I/O, and native extensions. See Mozilla’s “Oxidation” journey for context on swapping critical components with Rust.
– Background reading: Mozilla Hacks: Oxidizing Source Code. The Rust Programming Language.
– Today’s landscape: Bun is built around Zig and JavaScriptCore, while Deno runs on Rust + V8. Different bets; similar goals: speed, safety, and compatibility.
When a full rewrite makes sense
- Clear, recurring safety bugs in native code you can’t isolate or sandbox.
- Profiling shows persistent hot paths dominated by unsafe or hard-to-optimize code.
- Long-term maintainability is blocked by language/tooling debt, not just “taste.”
- Ecosystem parity is achievable (compat layers, test suites, and migration tooling are realistic within budget).
A safer hybrid: Rust where it counts
You don’t need to rewrite everything. Start by carving out hot paths or unsafe subsystems and replace them with Rust components behind stable boundaries.
- FFI boundaries: Use well-defined interfaces. For Node/Node-compatible layers, consider N-API. For Bun, explore bun:ffi. For bespoke runtimes, keep C ABI surfaces minimal and well-tested.
- Data interchange: Prefer zero-copy or bounded-copy designs; document ownership rules explicitly.
- Isolation: Sandbox risky parsers/codecs; fuzz Rust components early to shake out UB and panics.
Practical steps and metrics
- Set baselines: Throughput (req/s), tail latency (p99/p999), memory footprint, cold start, CPU%
- Trace first: Use flamegraphs and async-profiler to pick the top 1–3 hot paths
- Prototype in weeks, not months: Replace one subsystem with Rust; keep a kill switch
- Benchmark apples-to-apples: Same workloads, same hardware, reproducible scripts
- Compatibility gates: CI must pass spec suites and real-world fixture apps
- Security review: Threat-model FFI boundaries; add fuzzing and differential tests
Key risks to manage
- Rewrite trap: Shipping slips as “just one more subsystem” moves to Rust; time-box the scope
- Ecosystem drift: Compatibility layers (Node API, package managers) lag behind performance wins
- Talent mix: Rust expertise is critical; pair with domain experts from the current codebase
- Hidden costs: Build times, tooling, and debugging workflows can slow iteration if not planned
Bottom line
Rust can deliver real wins for runtimes — but success comes from surgical scope, strong boundaries, and ruthless benchmarking, not ideology.
Takeaway: Treat “rewrite in Rust” as a capability you apply to the noisiest 10% of performance/safety pain, prove impact, then expand deliberately.
Want more pragmatic AI and dev insights? Subscribe to our free newsletter: theainuggets.com/newsletter.
