C++

The language with probably the largest body of deployed code in this roster, absent from it until now. Like c, its identity is a document: ISO/IEC 14882, currently C++23 — "the standard is called C++23 because 2023 is the year the technical work was completed," while the ISO publication suffix reads :2024 for administrative reasons. ISO holds the copyright on every balloted version; working drafts live on GitHub and are explicitly "may frequently be in an inconsistent in-progress state." (isocpp.org, the committee's own site — T1 for facts about the standard.)

The revisions since 2011 land on a three-year cadence: C++11, C++14, C++17, C++20, C++23.

What the committee is, and what that does to the language

Stroustrup's HOPL IV paper describes the process from inside. Up to 250 people turn up to week-long meetings three times a year, with more participating electronically, and the standard "evolves through a consensus process. Inevitably, there is competition among proposals and clashes (usually polite ones) over direction, design philosophies, and principles."

His summary of the resulting pressure is the sharpest statement of the design problem this spoke has collected — three contradictory demands, held for decades:

• Make the language simpler! • Add these two essential features now!! • Don't break (any of) my code!!!

Note which one always wins. That is a governance fact as much as a technical one, and it belongs next to language-governance: a committee with no owner cannot break compatibility, because there is no one who could absorb the cost of doing it.

Adoption

From 2006 to 2020 the C++ developer community grew from about 3 million to about 4.5 million (cpp-hopl) — through a period when "quite a few well-financed and professionally marketed languages fought for dominance," and without commercial backing of its own. Growth, not merely survival, is the fact that needs explaining, and Stroustrup's answer is stability: people with significant applications want "comprehensive support, stability (compatibility), and familiarity," and "invariably confuse familiarity with simplicity and prefer familiarity over simplicity if given a choice."

Against the rest of the roster

• c takes the same document-as-identity route and answers the simplicity demand by declining the features. C++ answered it by adding them and keeping the old ones, which is why the language contains several eras at once.
• rust targets the same deployment space — no GC, no runtime — but is free to remove things, and its safety guarantee is the argument for paying migration cost. The zero-overhead principle Stroustrup cites (a feature you do not use should cost nothing) is the value both languages claim.
• go is the direct opposite of the C++ committee's outcome: every design move removes a choice. C++'s process cannot remove choices, only add.

The safety story, read 2026-08-22

The live question above is now sourced, and the answer has two halves that did not arrive together.

What was proposed: P3081, enforced bounds / type / lifetime / arithmetic profiles, every rule decidable at compile time and enforced by the compiler rather than a separate analyser, with granular per-profile opt-out. Explicitly not formal proof and not a new dialect — which is the ground on which Safe C++ (P3390, a borrow checker) was refused.

What shipped in C++26: not that. Per wg21-croydon-2026, profiles were deferred to C++29; C++26 got the elimination of undefined behaviour for uninitialized locals and a hardened standard library (cpp-library-hardening) — both of which apply to existing code on a recompile. The hardened library is the half with production evidence: 0.3% average overhead and roughly 30% fewer segfaults across Google's fleet, self-reported.

The pattern is the one this page already describes. The additive feature shipped; the one that would change what existing code compiles to is in its fourth year of proposal.

Still not read here: the standard text itself (it is sold, not published) and the library's shape.