Rust in Production: What Two Years of Systems Code Actually Looks Like

Two years ago I switched a project from C++ to Rust. I expected the memory safety pitch. I didn't expect how much the type system would change how I think about system design.

## What Actually Changed

The common narrative around Rust is "no memory bugs, safe concurrency." That's accurate but incomplete.

What two years of production Rust code taught me is that the borrow checker isn't just a safety mechanism — it's a **design pressure tool**. When the compiler rejects your ownership model, it's often because you've designed something ambiguous. Fixing it usually makes the architecture clearer.

That said, don't mistake this for free. The learning curve is real. The first three months, I was fighting the borrow checker more than writing actual logic.

> ⚡ Rust's compile times are genuinely painful in large codebases. Incremental compilation helps, but a full rebuild of a 200k-line project can hit 5–10 minutes. This is a workflow cost that doesn't show up in benchmarks.

## Where Rust Wins Clearly

After two years, here's where I'd reach for Rust without hesitation:

- **Network services with high concurrency**: `tokio`-based async I/O gives you C-level throughput without the footgun risks. No data races — and I mean the kind the compiler provably excludes, not the kind you hope your code review catches.
- **Anything that parses untrusted input**: Parsers written in safe Rust eliminate an entire class of buffer overflow and use-after-free bugs. This matters enormously for security-critical components.
- **Systems that need explicit memory layout control**: When you need to think in terms of cache lines and alignment, Rust lets you do that without giving up the type system.

## Where I'd Still Reach For C++

In my view, Rust is not the right choice for every systems project. Legacy codebases with C++ ABI requirements are an obvious case — the FFI boundary introduces overhead and complexity that often isn't worth it.

Real-time systems with hard latency requirements are more nuanced. Rust's allocator abstraction and drop semantics can introduce non-deterministic latency if you're not careful. It's solvable, but it requires expertise that most teams don't have yet.

## The Ecosystem Reality

`crates.io` is better than it was but the ecosystem is still maturing. For anything touching hardware-specific interfaces — SIMD intrinsics, platform-specific syscalls, GPU compute — you're often wrapping C libraries anyway. The Rust code becomes the orchestration layer, not the implementation.

---

Two years in: I'd make the same switch again. But I'd be more honest upfront with the team about the time investment. The safety guarantees are real. So is the learning cost.

## The Bigger Picture

Rust in the Linux kernel, Rust in Android system components, Rust in Windows kernel experiments — the adoption signals are clear. This isn't a niche language experiment anymore. The question isn't whether Rust matters to systems programming; it's how long the transition to a Rust-first mentality takes for the rest of the industry.

Probably longer than the enthusiasts think.

Rust in Production: What Two Years of Systems Code Actually Looks Like

// COMMENTS

ON THIS PAGE