C++23 Series: 0. Is C++ still worth it in 2026?
For the last few years, the tech industry has been flooded with “C++ is dead” headlines. Between the push of White House for memory-safe languages and the meteoric rise of Rust, it is easy to feel like C++ is slowly dying.
C++ isn’t just surviving… It is undergoing a massive architectural renaissance. With the full integration of C++23 — and the coming C++26 standard being baked—, we are seeing a language that finally prioritizes developer experience alongside its legendary performance. We have moved past the “C with Classes” era and even the “Modern C++11” era. We are now in the age of Scalable, Expressive C++.
The goal of this series isn’t to pretend C++ is perfect. It is to look at why it remains the backbone of our world — from the engines powering AAA games to the low-latency systems driving global finance — and how the C++23 standard fixes the pains that used to make development a chore.
Memory Safety
The criticism against C++ usually centres on one fact: it allows manual memory management. In the wrong hands, this leads to buffer overflows, use-after-free errors, and memory leaks. However, the narrative that C++ is inherently dangerous ignores the massive strides the language has made to protect developers from themselves.
The primary difference between C++ and Rust isn’t that C++ can’t be safe — it is that C++ gives you the keys to the engine. Rust enforces safety at the compiler level while Modern C++20/23 provides a safe subset. If you use smart pointers (std::unique_ptr, std::shared_ptr), containers (std::vector, std::array), and views (std::span, std::string_view), 90% of traditional memory bugs simply vanish.
C++23 introduced features that make “doing the right thing” the easiest path for the developer. The std::expected and std::optional extensions reduce the need for raw pointers to indicate null or error states. Instead of returning a pointer that might be null, you return a type that forces the caller to handle the error case. The std::span (introduced in C++20, refined in 23) allows us to pass arrays around without decaying them into dangerous raw pointers. It tracks the size automatically, preventing the classic out-of-bounds exploit.
The most exciting development is the progress of Bjarne Stroustrup’s profiles proposal. The goal is to allow developers to participate in specific safety guarantees at the compiler level. Imagine adding a single line to your build script: set_cpp_profile(type_safety, bounds_safety, memory_safety). The compiler would then flag any legacy or unsafe code as a hard error.
The Competitive Landscape: C++ vs. Rust vs. Carbon
Rust: The “Greenfield” Gold Standard
Rust has officially moved from a trendy alternative to a corporate essential. If you are starting a new security-sensitive project from scratch — like a cloud-native microservice or a new kernel module — Rust is often the default choice.
Its Borrow Checker provides safety guarantees that C++ can only mimic through discipline. While Rust-to-C interoperability is solid, Rust-to-C++ interoperability remains a complex — often painful — bridge to cross for large, template-heavy codebases.
Carbon: The “Successor” in the Wings
Google’s Carbon language is the one to watch if you are working in a massive C++ shop. As of early 2026, Carbon is approaching its 0.1 Evaluation milestone.
Carbon isn’t trying to replace C++ overnight. It is designed to be to C++ what TypeScript is to JavaScript: a language that can live inside your existing build system, allowing you to migrate one file at a time while maintaining bi-directional compatibility.
Still experimental, but the “successor” model is gaining traction among engineers who find Rust’s migration path too steep.
C++23/26: The “Ship of Theseus”
C++ is essentially rebuilding itself from the inside out. With C++26 drafts finalizing this year, features like compile-time reflection and contracts are narrowing the gap between C++ and its modern rivals. Counterintuitively, competition has made C++ stronger. According to recent 2026 industry data, C++ is actually adding more total developers annually than some of its replacements have in their entire ecosystems.
While AI models are written in Python, the inference engines and kernels — the code that runs on the GPU/NPU — are almost exclusively C++. As AI demand scales, the demand for the engineers who can squeeze every ounce of performance out of the silicon — the C++ engineers — has hit a ten-year high.
Conclusions
While C++23 gave us the tools to write cleaner code today, C++26 is aiming to solve the meta-problems that have plagued the language for decades. For the first time, the language will have a standardized way to inspect its own types at compile time. This means that tedious, error-prone tasks like writing serialization code, ORM mapping, or even simple enum-to-string conversions can be automated entirely within the compiler.
After nearly two decades of debate, the contracts MVP allows developers to formally define preconditions, postconditions, and assertions. This doesn’t just help with debugging — it serves as a bridge for the memory safety conversation by allowing compilers and static analysis tools to prove that your code is behaving exactly as intended. When combined with the new Hardened Standard Library mode, C++26 allows you to simply recompile existing code to gain immediate, automated bounds-checking across your most-used containers.
Finally, we are seeing the industrialization of the C++ ecosystem. Tools like Visual Studio 2026 and the latest Clang/GCC releases are integrating AI-powered lifetime tracking and sophisticated modules support that finally makes “import std;” a production reality. The worth of C++ in 2026 isn’t just about speed anymore — it is about the fact that we are finally getting a language that is as expressive and safe as its modern rivals, without losing the zero-overhead soul that made it the foundation of the digital world in the first place.