Insights from a panel discussion featuring Herb Sutter, Gašper Ažman, Timur Doumler, Juan Alday and Carl Cook
Key Takeaways
- Many engineers see C++26 as the first release since C++11 that’s capable of materially reshaping day-to-day systems programming.
- Reflection, contracts and structured execution all point toward the same shift: expressing developer intent more directly in code.
- Finance is helping to drive many of these abstractions because low-latency systems expose the limits of existing models faster than most industries.
- The dominant conversation around C++ has shifted from inventing abstractions to operationalizing them at scale.
For years, conversations about modern C++ have focused on individual features, i.e., modules, coroutines, concepts, reflection and contracts. At a recent panel discussion in London, however, a different picture emerged.
The discussion was about a broader shift in systems programming itself. Modern infrastructure has become too concurrent, performance-sensitive and operationally complex for many older programming models to scale cleanly.
That is the backdrop against which C++26 is arriving.
From “How” to “What”
Modern C++ is increasingly about expressing intent.
Historically, systems programming required developers to describe threading behavior, memory management, synchronization, correctness guarantees and hardware interaction manually. That control made C++ powerful, but it also forced enormous implementation complexity directly into software systems.
C++26’s major features share a common theme:
- Reflection expresses structural intent.
- Contracts express correctness intent.
- Structured execution expresses concurrency intent.
Together, these features move C++ toward a more declarative style of systems programming without giving up low-level control. Unlike higher-level languages that hide the machine, these features are designed as zero-overhead abstractions. They allow developers to express intent clearly while still compiling down to the same—or better—raw assembly as hand-crafted C code but without the boilerplate that produces human error.
The goal isn’t abstraction for abstraction’s sake, but abstraction that remains predictable under load, transparent to engineers and efficient at the hardware level.
Several panelists framed this as the natural next phase of the language’s evolution.
Why Finance Is Shaping the Conversation
Modern C++ is being heavily influenced by low-latency systems engineering, particularly in finance.
These environments operate under unusually hard constraints, involving deterministic latency requirements, massive concurrency, strict correctness guarantees and the constant pressure to eliminate unpredictability. In those systems, abstraction costs surface immediately. While the absolute hottest paths in trading algorithms may still rely on raw, bare-metal memory manipulation, the massive concurrent infrastructure surrounding those paths can’t be managed safely with manual POSIX threads and raw pointers.
Additionally, concurrency models that introduce hidden allocations, unstable execution behavior or unpredictable scheduling simply don’t survive for long in production.
That helps explain why finance has such an outsized influence on modern C++’s evolution. Timur Doumler noted that finance played a major role in pushing contracts forward, calling it “absolutely not a coincidence.”
The same mindset shaped the discussion around execution and sender/receiver models. The question was whether abstractions could scale operationally without compromising latency, compile times or determinism.
That perspective gave the conversation a pragmatic tone.
Why C++26 Feels Different from C++20
The panel drew an important distinction between C++20 and C++26.
C++20 introduced foundational capabilities like modules, coroutines and concepts. But many teams struggled to operationalize them quickly. Tooling maturity, portability and implementation quality lagged behind the abstractions themselves. Because these were massive paradigm shifts rather than incremental updates, compiler technology required a maturation period.
C++26 feels different because the conversation has shifted from invention to usability.
The abstractions are now largely understood. The challenge is making them production-ready by reducing friction, preserving compile times, improving interoperability and maintaining deterministic behavior.
For example, early template-heavy concurrency models were infamous for bloating build times. Gašper Ažman described reducing compile-time scaling problems in sender/receiver implementations from quadratic behavior to linear behavior, demonstrating that these modern abstractions can be deployed without hindering the build pipeline.
That anecdote reflected a broader shift: The bottleneck in systems programming is ecosystem maturity, not conceptual capability.
Correctness Is Now Directly Expressible in Code
Historically, systems programming often treated correctness and performance as competing priorities. Stronger guarantees usually imply more overhead, more abstraction or less control.
The panel suggested that this tradeoff is changing.
Contracts were central to that discussion because they allow systems to explicitly express correctness by annotating C++ code with preconditions and postconditions and having them checked and/or enforced optionally at runtime. Unlike traditional, macro-based runtime checks (like C’s assert()), contracts provide a standardized, compiler-integrated vocabulary. Being able to expose these correctness conditions explicitly on the function declaration greatly enhances the ability of human developers, compilers, static analyzers, IDEs and LLMs to reason about code correctness, as they don’t have to analyze the function implementation anymore—which might be difficult or impossible. Code is no longer written solely for humans and compilers. It’s also written for static analysis systems, IDEs, verification tooling and AI-assisted development systems. Modern software systems have become too large and interconnected for correctness to remain informal.
AI Raises the Value of Systems Judgment
The panel concluded with a discussion about AI-assisted development. The most interesting insight wasn’t what AI improves but what it doesn’t replace.
AI already makes engineering tasks like onboarding into large codebases, refactoring, documentation, test generation and navigating unfamiliar systems cheaper. But several panelists argued that as routine engineering work becomes cheaper, architectural reasoning becomes more valuable.
AI can often explain code. Because modern C++ enforces strict type safety, memory models and explicit contracts, the compiler acts as a rigid guardrail against AI-generated hallucinations.
It can’t reliably design low-latency systems with deep awareness of concurrency, operational constraints, hardware behavior and long-term maintainability yet. Scale and quality are not growing in equal measure, and more “good-enough code” could come at the cost of invisible technical debt.
And, importantly, AI can’t solve new problems.
In that sense, AI amplifies the same trend visible throughout modern C++ itself: Higher-level abstractions make understanding the underlying system all the more important, presenting an opportunity for engineers to lean into work that maximizes their contributions.
The Bigger Meaning of C++26
C++26 introduces powerful new, critical features that have compounding user benefits, indicating that the language may be entering a new phase of maturity.
C++ is evolving by becoming better at expressing intent while preserving control.
Building abstractions that remain efficient, transparent and predictable close to the hardware has always been the central challenge in systems programming. And we aren’t abstracting because we forgot how hardware works; we’re abstracting because our systems have become too large and concurrent for manual, C-style micromanagement to be safe or scalable.
According to many of the engineers on the panel, C++26 is the clearest answer to that challenge yet.
