Memory Safety Is No Longer Optional

A few years ago, saying "you should use a memory-safe language" in the wrong room would get you dismissed as impractical. Systems programming meant C or C++. The ecosystem, the tooling, the talent — all of it pointed there. Memory safety was a nice-to-have that was perpetually scheduled for "later."

Later has arrived.

The Weight of Evidence

The numbers have become undeniable. Microsoft has repeatedly reported that roughly 70% of its security vulnerabilities are caused by memory safety errors. Google's Project Zero tracks zero-days; a disproportionate share trace back to use-after-free bugs, buffer overflows, and other memory corruption issues that memory-safe languages eliminate by construction.

These aren't edge cases. They're the texture of software security as it actually exists: an unending treadmill of patches for a class of bugs that should not be possible in 2026.

What "Memory Safety" Actually Means

It's worth being precise. Memory-safe languages prevent:

• Buffer overflows: Writing past the end of an allocated region
• Use-after-free: Accessing memory after it's been deallocated
• Double-frees: Freeing the same memory region twice
• Dangling pointers: Holding a reference to memory that's been returned to the allocator
• Null pointer dereferences (in languages with robust type systems)

They do this through a combination of techniques: garbage collection (Go, Java, Python), ownership systems (Rust), or strict borrowing rules enforced at compile time.

Rust's Moment

Rust has become the focus of most serious discussion about systems-level memory safety. It offers performance characteristics close to C and C++ — no garbage collector, zero-cost abstractions, direct memory control — while enforcing safety at compile time through its ownership and borrowing model.

The learning curve is real and steep. The borrow checker rejects programs that C would compile without complaint. This frustrates developers trained on more permissive languages. It's also exactly the point.

What the borrow checker rejects at compile time can't become a CVE at runtime.

Where Things Stand

Rust has now shipped in the Linux kernel, in Android's core components, in Windows infrastructure, and in a long list of production services at companies that care deeply about security. The NSA and CISA have both published guidance recommending memory-safe languages for new development.

The conversation has moved from "should we?" to "how quickly can we migrate existing codebases?" — which is a genuinely hard engineering problem. You don't rewrite millions of lines of C overnight. But the direction is clear.

For greenfield development in domains where security matters — which is most domains — the question of whether to use a memory-safe language has become easier to answer than ever before.