Rust and C++ both compile to native code with no garbage collector, so speed rarely settles the Rust vs C++ question. In 2026 the decision turns on memory-safety exposure, what a migration would cost, how well the two languages interoperate, and which engineers you can hire. This article is current as of 7 October 2026.
The short answer: Rust or C++ for your component?
Start from what you already own. Greenfield code with an attack surface is the one case where the answer is clear.
| Situation | Pick | Why |
|---|---|---|
| New network-facing or security-sensitive component, no legacy code | Rust (or another memory safe language) | The White House ONCD report says choosing a memory safe language for new products is an early architecture decision |
| Large existing C++ codebase | Stay on C++, adopt C++26 hardening, rewrite only the highest-risk modules | ONCD suggests prioritising critical functions and libraries by risk and rewriting those first; the pick itself is our judgment |
| Game engine or toolchain tied to C++ | C++ | The ecosystem you depend on is C++ (judgment) |
| Embedded or kernel-adjacent driver work | Rust is viable | Android uses Rust as a platform language and the Linux kernel has merged Rust support |
| Small team of mixed seniority | Either, with a higher hiring bar than usual | Both languages punish inexperience, in different ways (judgment) |
Where the pick isn't "Rust or C++" at all, it's Rust or Go, Java or C#. If your component isn't systems code, read choosing between Go and Rust for a backend team first.
What do CISA, NSA and the White House say about C++?
They say C++ is a risk and that new work should start in a memory safe language. They don't ban it.
The February 2024 White House ONCD report, Back to the Building Blocks, says that "Experts have identified a few programming languages that both lack traits associated with memory safety and also have high proliferation across critical systems, such as C and C++." It adds that "For new products, choosing to build in a memory safe programming language is an early architecture decision that can deliver significant security benefits." For existing code it suggests that "software developers can identify the critical functions or libraries based on risk criteria and prioritize efforts to rewrite those first." The report cites industry analysis showing, in some cases, that up to 70 percent of security vulnerabilities in memory unsafe languages patched and assigned a CVE designation are due to memory safety issues, and says that when large code bases are migrated to a memory safe language, evidence shows memory safety vulnerabilities are nearly eliminated.
CISA and NSA followed in June 2025 with a joint guide, announced in CISA's alert on reducing memory-related vulnerabilities. It's titled "Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development" and presents adopting memory safe languages as the main mitigation it recommends for this class of vulnerabilities. The alert says organisations in academia, government and private industry are "encouraged to review this guidance and support adoption of MSLs."
Read that language carefully. It's encouragement. We found no deadline for private companies in the pages we read, and no ban on C++. The guidance is about memory safe languages as a category, not Rust alone. In our judgment, for many teams the real comparison is Rust against a garbage-collected language. The practical effect is on procurement and questionnaires: a customer can point to these documents and ask why your new native service is written in C++.
What C++26 changes (and what it doesn't)
C++26 closes some of the gap, though not all of it. In his March 2026 trip report, Herb Sutter wrote that "the ISO C++ committee completed technical work on C++26" at its London Croydon meeting. The committee is now producing the final document for its international approval ballot (the Draft International Standard stage).
So C++26 is technically complete but not yet published. The current ISO standard, per the Standard C++ Foundation's standard page, is C++23, formally ISO/IEC 14882:2024.
Two safety changes matter most, both from Sutter's report. First, "No more undefined behavior (UB) for reading uninitialized local variables. This whole category of potential vulnerabilities disappears in C++26, just by recompiling your code as C++26." Second, a hardened standard library that provides "bounds safety for dozens of the most widely used bounded operations on common standard types, including vector, span, string, string_view, and more." Sutter reports that at Google alone the hardening "has already fixed over 1,000 bugs" and "has reduced the segfault rate across the production fleet by 30%."
That's a real improvement for existing code, and it costs a recompile rather than a rewrite. It doesn't give C++ Rust's compile-time ownership checks. Sutter's report says a major focus of the discussion about C++29-timeframe material was further increasing memory safety, so more safety work is aimed at the next standard. We haven't confirmed which compilers ship the C++26 hardening or when, so check your toolchain before planning around it.
Where Rust is already in production systems code
Rust isn't a bet any more in the two places where C and C++ have long been the default.
Android's memory safety documentation says that "Memory safety bugs account for over 60% of high severity security vulnerabilities" and that native code in C, C++ and Assembly makes up over 70% of the platform. It also states that "Android 12 introduced Rust as a platform language" and, in the project's own words, "We expect Rust to be the preferred choice for most new native projects." That's Google's Android memory safety page, so it's the platform owner's position, not an independent assessment.
The Linux kernel merged Rust support in v6.1. In December 2025 Miguel Ojeda sent a patch titled "rust: conclude the Rust experiment" that deletes the documentation section describing Rust support as an experiment. His message says "Rust is here to stay." The patch changes only that documentation section and removes no code.
Performance and interop: what you can conclude
Both languages avoid a garbage collector, and both give you control over memory layout. Rust's own site claims that "with no runtime or garbage collector, it can power performance-critical services, run on embedded devices, and easily integrate with other languages," and Android says Rust provides "memory and thread safety at performance levels similar to C/C++." Those are vendor positions, not measurements.
We haven't found a neutral benchmark we'd trust, and several pages that rank for this query print figures with no method, so we haven't repeated any. If performance decides your choice, write the hot path in both and measure it on your hardware. The honest summary is that neither language is slow, and the difference you'll feel is usually in engineering time.
Interop is where real projects live. Mixed C++ and Rust codebases are normal, and the boundary between them is where bugs concentrate, because unsafe code and foreign function calls sit exactly there. Our judgment is that the boundary needs a named owner.
For currency, Rust 1.99.0 shipped on 1 October 2026, per the Rust 1.99 announcement.
What do the surveys say about the hiring pool?
C++ has the larger pool, but Rust's isn't small. Stack Overflow's 2025 developer survey asked which languages respondents had done extensive development work in over the past year. Among all 31,771 respondents who answered, 23.5% said C++ and 14.8% said Rust. Among the 24,759 professional developers, it was 21.8% for C++ and 14.5% for Rust, a ratio of about 1.5 to 1 (calculated from those two figures).
Treat that as a rough guide. The survey is self-selected, and it measures recent work, not availability. It says nothing about seniority or location, and someone who wrote Rust last month isn't necessarily looking. We also have no sourced figure for salary or time to hire, so we haven't included one.
The other signal is demand. The 2025 State of Rust survey collected 7,156 responses and says the results "Confirmed the hiring trend from organisations looking for more Rust developers." It also notes that slow compile times and storage usage are "still up there" among the challenges. Build times remain a top challenge in the survey, so plan for them.
Rust vs C++ side by side
| Criterion | C++ | Rust |
|---|---|---|
| Current standard or release (7 Oct 2026) | C++23 published; C++26 technically complete (March 2026), ballot pending | 1.99.0 (1 Oct 2026) |
| Memory model | Manual, with smart pointers; hardened library and no UB for uninitialized local reads in C++26 | Ownership and borrowing checked at compile time |
| Government guidance | Named by ONCD as lacking memory safety traits | Ownership model claimed by the Rust project to guarantee memory safety |
| Professional survey share (Stack Overflow 2025) | 21.8% | 14.5% |
| Governance | ISO committee | Rust project |
| Systems footprint | Android native code is over 70% C, C++ and Assembly | Android platform language since Android 12; Linux kernel documentation no longer calls Rust an experiment |
| Screening focus | Modern C++ habits, sanitizers, build systems | Ownership reasoning, unsafe discipline, async |
What to screen for in each hire
For C++ engineers:
- Modern habits: RAII, smart pointers and C++20/23 idioms, as opposed to a legacy style that predates them
- Sanitizer and static-analysis practice, and whether they run them by default
- Build-system fluency, since a lot of C++ pain lives in the build
For Rust engineers:
- Ownership reasoning: can they explain why the compiler rejected something instead of cloning until it passes
unsafediscipline, and how they design the foreign function boundary with C++- Async judgment, including runtime choice and what the thread-safety rules mean for their design
For Rust, vetting a Rust engineer's ownership and async judgment covers the full process.
What this means for your native-component decision
Our judgment, backed by the ONCD new-products language, is to default to Rust or a managed memory safe language for new native code with an exposure surface, and be ready to say why when a customer security questionnaire or your board asks. "We chose C++ because the team knows it" is an answer, but it's one you should choose deliberately.
For an existing C++ estate, don't plan a rewrite. Adopt the C++26 hardening once your compilers support it, ring-fence the modules that parse untrusted input, and rewrite those first. Name a migration owner and budget the migration as technical debt rather than hoping it fits between features.
On the team side, plan a Rust ramp for your C++ engineers (our judgment, not a sourced figure). The pool is smaller than C++, though not niche. For the other stacks you may be sizing at the same time, see Hire developers by tech stack: rates, vetting and interview guides.
FAQ
Is Rust faster than C++?
We haven't found a neutral benchmark we'd stand behind. Both compile to native code with no garbage collector, and Android says Rust offers performance "similar to C/C++." Measure your own hot path.
Is Rust replacing C++?
No. C++26 is technically complete, Stack Overflow's 2025 survey shows more professional developers doing recent C++ work than Rust, and in our judgment most existing C++ code will stay. What's changing is the default for new security-sensitive components, which government guidance now points toward memory safe languages.
Is C++ memory safe?
Not by default. The ONCD report names C and C++ as lacking memory safety traits. C++26 removes undefined behaviour for reading uninitialized local variables and adds a hardened standard library with bounds checks, which helps, but it doesn't add Rust-style compile-time ownership checks.
Is Rust harder to learn than C++?
We don't have sourced data on this. In our judgment, Rust front-loads the difficulty (the compiler rejects code until ownership is right), while C++ lets you write the bug and find it later. Plan a ramp for either.
Which is easier to hire for?
C++, by a margin. Among professional developers in Stack Overflow's 2025 survey, 21.8% reported extensive C++ work in the past year against 14.5% for Rust. That's a global figure, not a count of engineers available in your market.
Can you mix Rust and C++ in one codebase?
Yes, and many teams do. Rust's site says it can "easily integrate with other languages." The boundary is where bugs concentrate, so give it an owner and review it closely.