Is C++ Dead?

C++ is still under attack in 2026. My identity is so entwined with coding in C++ that I feel attacked too. I dove into the latest reports, safety guidance, and C++26 updates so you don’t have to.

According to the January TIOBE Index, C++ is currently the fourth most popular programming language after C and Python. C++ is the main programming language used in many critical systems, including hospitals, cars, and airplanes. But dare I say it: C++ is prone to errors. And in 2024, even the U.S. government chipped in. They dropped the bomb: C and C++ are not memory-safe programming languages. In 2026, might C++ be seeing its last days?

The Software Memory Safety Cybersecurity Information Sheet highlights how malicious actors can exploit poor memory management to access sensitive information, execute unauthorized code, and cause other negative impacts. Microsoft and Google have admitted that memory safety issues account for about 70% of their vulnerabilities. Poor memory management can also lead to technical issues, such as incorrect program results, degradation of performance over time, and program crashes.

Those are serious allegations. Are they substantiated?

The short answer is, unfortunately, yes. Since the beginning of C++, the language has prioritized performance over memory safety. C++ has received many claims of being memory-unsafe because it does not, by default, prevent code from performing unsafe memory operations, including accessing deallocated memory, accessing memory out of bounds, forgetting to free memory, freeing memory twice, and similar mistakes.

You might suggest fixing C++ and eliminating these issues. Unfortunately, this isn’t trivial for multiple reasons. The main reason is that the C++ committee always prioritizes backward compatibility when making changes. This means any C++ code that exists today must continue working with new versions of the language. We can’t just change everything because it would break old code. Certain early design decisions in C++ cannot be changed today.

For example, in C++, local primitive-type variables such as integers are not automatically initialized by default. This can offer a slight performance benefit if the variable is later initialized, avoiding an unnecessary initial assignment. However, reading an uninitialized variable triggers undefined behavior because the memory it points to may contain garbage data. Changing this behavior could impact existing code, even if the performance gain is negligible. There is a proposal to zero-initialize by default. Another proposal voted into C++26 suggests that instead of initializing variables to zero, the fixed value is defined by the implementation. Reading that value is now a conceptual error rather than undefined behavior.

Another common memory issue in C++ (and C) involves dereferencing a null pointer. The compiler may assume that all referenced pointers point to valid memory. It is up to the programmer to ensure correctness. Attempting to access a nullptr can lead to serious security vulnerabilities. Modifying C++ so the compiler automatically checks every pointer access would impose significant performance and implementation overhead.

At the same time, we should be precise about what “unsafe” means here. In a December 2025 article, Herb Sutter points out that if you look at MITRE’s 2025 CWE Top 25 list of software weaknesses, only a minority of the most dangerous entries are about type or memory safety in the programming language; most are higher-level design, authentication, and configuration problems. He also notes that most public vulnerability statistics still lump C and C++ together, even though the one reputable study that separates them (by Mend.io) shows C++ behaving much more like other modern languages than like C. That doesn’t magically make C++ safe, but it does mean that headline statistics about “C/C++” overstate the situation for idiomatic, modern C++ code.

Some developers are switching to alternative programming languages. The advantage of creating a new language is that you don’t have to maintain compatibility with old code. You can learn from design mistakes in other languages and correct them. This is what has happened with Rust. When considering alternatives to C++, Rust is the most frequently mentioned. It has similar performance to C++ but better defaults and, importantly, built-in static analysis. For instance, it can detect lifetime issues with its borrow checker.

While Rust is maturing, many existing systems still rely heavily on C++, and migrating them would be costly, especially since much software depends on C++ libraries. For example, I personally use the JUCE C++ framework extensively for developing audio software across desktop, mobile, and embedded platforms. JUCE is cross-platform and abstracts native graphics and audio APIs. It has been continuously improved since its release in 2004. Currently, no equivalent to JUCE exists in Rust, and so many colleagues and I continue to use C++. That said, Rust is gaining attention in the audio software community, particularly for the DSP (digital signal processing) part of the software.

In DAW Frontend Development Struggles, Billy Messenger explores challenges of building a DAW (Digital Audio Workstation) frontend. He considers Rust GUI libraries like Iced but raises concerns about performance and the learning curve, noting that Rust GUI libraries often have unfamiliar concepts. Outside the audio community, Rust is also gaining traction. Dropbox rewrote its sync engine, Nucleus, in Rust to overcome scalability, concurrency, and testing limitations. In a podcast, Daniel Stenberg, founder and lead developer of the curl project, mentioned attempting to integrate Rust as a backend for libcurl but encountering a Rust networking library that did not meet his requirements.

While Rust helps prevent memory safety issues, it cannot eliminate all types of bugs. The recent Cloudflare outage was caused by an unhandled error resulting from a developer’s mistake, and a vulnerability was recently discovered in sudo-rs, which shows that even memory-safe languages cannot prevent every problem.

At this moment, Rust seems suitable for small, specific backend tasks. If you want the maturity of C++, with its years of history, libraries, and large community, it may be best to stick with C++ and adopt its latest features.

C++ isn’t dying, it’s improving more than many realize.

The last few years of data back this up. Sutter’s article summarizes SlashData’s 2025 developer survey and shows that between 2022 and 2025, C++ and Rust were the two fastest-growing major programming languages. The global developer population grew from a little over 31 million to just over 47 million in that period, and Sutter reports that each of C++, Python, and Java added roughly a Rust-sized population of new developers in a single year.

Hyperscalers are now constrained more by megawatts than by GPU counts, so languages that maximize performance per watt and per transistor – C, C++, Rust – remain structurally important, especially for AI and large-scale backend systems. In that world, C++ is not quietly fading away while memory-safe languages take over; instead, C++ and Rust are growing together, each carving out its own place in the systems programming landscape.

Additionally, according to a recent ISO C++ survey, only 30% of C++ developers use a C++20 compiler or later. At using std::cpp Klaus Iglberger highlighted the real problem: not C++ itself, but how developers use it. Many developers are unaware of modern features and best practices. With new C++ versions coming out, teaching materials must be updated to ensure developers use recommended features.

C++26, potentially the biggest update since 2011, is now essentially baked and on track for publication this year. C++ is already a powerful language for generic programming but its upcoming feature, Reflection, takes this a step further. Reflection allows programs to inspect and manipulate their structure and metadata. It enables more generic, introspective, and metaprogramming capabilities, reducing boilerplate and improving code adaptability. Another improvement to C++, as mentioned earlier, C++26 will include erroneous behavior detection. But even in the current state of C++23, many things can be done to make the language safer to use. For instance, Bjarne Stroustrup, C++’s creator, recently published a paper demonstrating solutions for integer narrowing problems using a Number<T> abstraction.

Sutter’s also highlights that C++26 is not just adding “nice-to-have” abstractions, but actively hardening the language and library. First, C++26 removes undefined behavior for uninitialized local variables, turning a long-standing class of footguns into defined, diagnosable behavior. Second, the new hardened mode of the C++ standard library adds bounds checks to the most widely used container and string operations. In joint work between Apple and Google, a hardened libc++ has already been deployed across hundreds of millions of lines of production code with only fraction-of-a-percent overhead, and is projected to prevent on the order of one to two thousand bugs per year at Google alone. Finally, contracts (preconditions, postconditions, and assertions) give C++ a first-class way to express functional safety guarantees directly in code.

After reviewing these articles and talks, I am convinced that C++ isn’t near its last breath. However, the community must take responsibility and use the solutions available. C++ developers can, and should, write safe code in critical systems. The encouraging part, looking at Sutter’s 2025 numbers, is that C++ usage is still growing rapidly; the challenge for 2026 and beyond is making sure that growth is concentrated in modern codebases that take safety, hardening, and up-to-date C++ seriously.