The invisible tax of C++
A developer's account of switching from C++ to Rust after years in production codebases highlights something CTOs should note: the real cost isn't in the language features, it's in where engineers spend their mental energy.
The piece articulates what experienced C++ teams know but rarely quantify: there's an invisible checklist running constantly. Null pointers. Dangling references. Use-after-free. Double-frees. Undefined behavior that passes code review and ships to production.
Microsoft's data makes this concrete: 70% of their security vulnerabilities trace to memory safety issues. Google Chromium reports similar numbers. This isn't theoretical.
The trade-off that matters
Rust's borrow checker stops you immediately - at compile time, while you're still in context. The author frames this as "a gift," which sounds like developer enthusiasm until you consider the alternative: debugging memory issues weeks after commit, or worse, never catching them at all.
The distinction the author draws is worth considering: C++ builds avoidant muscle memory (what not to do), Rust builds constructive patterns (what actually works). One is a growing list of traps to dodge. The other is enforced by the compiler.
This matches what we're seeing in the field. Linux kernel modules are being written in Rust. Firefox components have migrated. Not because Rust is faster - it's not always - but because the safety guarantees are baked in, not bolted on.
The implementation reality
Fair criticism: Rust has a steeper learning curve. Slower compiles. Smaller talent pool. The C++ camp, including Stroustrup, argues modern C++ features can achieve similar safety with discipline.
History suggests otherwise. CISA's January 2026 memory safety roadmap deadline for legacy C/C++ products isn't arbitrary. The pattern is clear: conscientious C++ teams can approach zero faults, but it requires constant vigilance. Rust automates that vigilance.
The question for enterprise teams isn't "which language is better" - it's where you want your engineers spending cognitive cycles. On domain logic and architecture, or on manually enforcing what the compiler could check?
For greenfield projects with long support timelines, that trade-off increasingly favors compile-time safety. The cost is front-loaded. The benefit compounds.
What this means in practice
If you're managing C++ codebases, this isn't a call to rewrite everything. Tools like c2rust, bindgen, and cxx exist for incremental migration, though the unsafe code blocks still require manual review.
But for new infrastructure projects - especially anything security-critical - the risk calculus has shifted. The "invisible checklist" the author describes? It has a real cost, even if it doesn't show up in your sprint velocity metrics.
Worth noting: the author describes this as a personal preference, not an objective truth. That intellectual honesty matters. But when 70% of your security budget traces to memory safety, preferences start looking like data points.