Why I'm Betting on Rust for the Next Decade of Infrastructure

For most of the last twenty years, infrastructure teams made a quiet trade-off: we accepted memory-unsafe systems software because it was fast, mature, and everywhere. C and C++ powered operating systems, proxies, packet processors, hypervisors, and the invisible plumbing of the internet. The performance was excellent. The operational cost was hidden in incident queues, emergency patches, and the permanent background anxiety that one parsing bug could become a very public failure.

I don't think that trade still makes sense.

That is why I'm betting on Rust for the next decade of infrastructure—not as a fashionable language choice, not as a recruiting slogan, and not because every old component should be rewritten tomorrow. I'm betting on it because the economics of reliability have changed. The systems we run are more exposed, more distributed, more automated, and less forgiving than the ones we built ten years ago. In that world, memory safety is no longer a nice-to-have. It is table stakes.

The old bargain is breaking

Classic infrastructure software was built in an era where the dominant assumption was scarcity: scarce CPU, scarce memory, scarce bandwidth, scarce abstraction. If you wanted maximum throughput, you got close to the metal. That decision made sense. A few percentage points of performance could determine whether a box survived peak traffic or collapsed under load.

But modern infrastructure is constrained by something else as well: operational complexity. We are no longer just optimizing for raw speed. We are optimizing for patch velocity, exploit resistance, maintainability, team leverage, and confidence under stress.

Look at the last decade of critical vulnerabilities and a pattern emerges. A depressing amount of internet risk still comes down to software doing unsafe things with memory: buffer overflows, use-after-free errors, dangling pointers, undefined behavior hiding in code paths nobody meant to touch. These are not glamorous failures. They are expensive failures. They create midnight pages, emergency maintenance windows, reputation damage, and very long weeks for senior engineers.

When a whole class of bug keeps reappearing across products, vendors, and decades, the honest conclusion is not “we need to be more careful.” The honest conclusion is “the toolchain is allowing failure modes we can no longer afford.”

Infrastructure is now a security product, whether you like it or not

One of the biggest mindset shifts in modern engineering is that every infrastructure component is also part of your security boundary. Your load balancer is not just a traffic shaper. Your parser is not just a parser. Your observability agent is not just collecting metrics. Each one is a potential entry point, privilege escalation path, or blast-radius multiplier.

That matters because the old separation between “performance engineering” and “security engineering” is collapsing. In critical infrastructure, the safest component increasingly wins—not only because it avoids exploitation, but because it reduces the cognitive load of operating at scale.

Rust changes that equation. It does not make software bug-free. Anyone selling that story is oversimplifying. What it does is eliminate large categories of bugs before they make it to production. Ownership, borrowing, and the compiler's strictness feel inconvenient exactly once: during development. After that, they become a compounding asset. You pay more attention upfront so you can spend less time apologizing later.

For teams responsible for resilient internet services, that is a fantastic trade.

Performance still matters. Rust just changes the price of getting it.

The argument against safer languages used to be straightforward: safety costs too much. Higher-level runtimes introduced garbage collection pauses, bigger memory footprints, unpredictable latency, or limited systems access. So teams accepted unsafe languages because the alternatives were operationally unacceptable for low-latency or high-throughput workloads.

Rust is different because it does not ask infrastructure teams to choose between control and safety. You still get deterministic performance characteristics. You still get native binaries. You still get tight control over memory layout, concurrency, and interfaces to the kernel. But you get those benefits with much stronger guarantees about what the code is allowed to do.

That is the strategic unlock. Rust narrows the historical gap between “fast enough to trust in production” and “safe enough to sleep at night.”

And yes, there is a learning curve. The compiler can be unforgiving. The first months are slower. People complain that the language “fights back.” My view is simple: if the language forces a difficult conversation with your design before your customers have that conversation with your outage page, that is not friction. That is leverage.

Where Rust already makes obvious sense

I would not recommend rewriting an entire estate just because a new language is attractive. Rewrites are where good intentions go to die. But there are clear categories where Rust is already an obvious choice for new infrastructure work:

• Network-facing services such as proxies, gateways, packet filters, and protocol terminators that parse hostile input all day long.
• Security-sensitive agents that run with elevated privileges on customer or production systems.
• High-concurrency control planes where correctness under load matters more than clever abstractions.
• CLI and operational tooling where distributing a single static binary removes entire classes of deployment pain.
• Performance-critical replacement components where teams have already identified a hot path and want both speed and hardening.

These are the areas where one exploit or one undefined behavior bug can have disproportionate consequences. If I have to choose where to spend engineering effort, I would rather harden the parts of the stack that sit closest to untrusted input and deepest in privileged execution paths.

The real return is organizational, not just technical

Most language debates are framed as engineering preference. I think that misses the bigger point. The return on Rust is not only in benchmark numbers or CVE reduction. The deeper return is organizational.

Every class of bug you eliminate changes how a team behaves. Reviews get sharper because reviewers can focus more on architecture and less on pointer paranoia. On-call gets calmer because fewer incidents trace back to invisible memory corruption. Security teams gain confidence because the attack surface shrinks in meaningful ways. New engineers inherit systems with clearer contracts. Over time, the culture moves from “be very careful” to “the system helps us do the right thing.”

That is what mature infrastructure organizations should want: not heroics, but constraints that make reliability more normal.

Too many companies still confuse resilience with the presence of experts who can save a broken system. Real resilience is when the system fails less often because the design made entire failure modes harder to introduce in the first place.

Why this decade is different

There is also a timing reason behind my conviction. Infrastructure is entering a decade defined by three pressures at once: AI-scale demand, geopolitical pressure on digital sovereignty, and a much more hostile threat landscape. That combination raises the standard for what “production-ready” means.

We need systems that are efficient enough to handle heavier workloads, portable enough to avoid strategic dependency traps, and robust enough to survive increasingly sophisticated attacks. The old operating model of “ship fast, patch later” is becoming indefensible for core infrastructure.

Rust fits this moment unusually well. It produces portable binaries, integrates cleanly with low-level systems, performs well under pressure, and aligns with a world where software assurance matters more every quarter. It is not the only language that matters, but it is the one most aligned with the constraints we are actually facing.

What I would not do

Let me be equally clear about what I would not do.

• I would not rewrite stable, low-risk systems with no clear benefit just to modernize a stack diagram.
• I would not force every engineer to become a Rust engineer overnight.
• I would not pretend ecosystem maturity is identical across every domain.
• I would not use Rust where a simpler language is obviously better for product iteration and operational speed.

Language strategy should be portfolio strategy. Use the right tool for the risk profile of the component. My argument is not that Rust should eat all software. My argument is that it should increasingly own the parts of infrastructure where failure is both expensive and avoidable.

The winning architecture is safer by default

When I look at the next decade of resilient infrastructure, I see a simple pattern: the best systems will not just be faster or cheaper. They will be safer by default. Safer to modify. Safer to expose. Safer to automate. Safer to trust with critical paths.

That is why Rust matters. Not because it is trendy, but because it gives infrastructure teams something they rarely get offered at the same time: better performance economics and better failure economics.

In the early internet, we accepted fragility because the upside of speed was overwhelming. In the modern internet, fragility is often the cost center that destroys the value speed created. The companies that understand this shift early will build systems that are not only efficient, but durable.

That is the real bet.

The next decade of infrastructure will belong to teams that treat safety as a primitive, not a patch. Rust is not the whole story. But I am convinced it will be one of its defining languages.

---