Prologue — "C++ is dead" dies again every year

All through the 2010s, C++ got a fresh obituary every year. When Go appeared. When Rust appeared. When Swift appeared. When Zig appeared. Each time the story was "now system programming will move to X." As of May 2026, the prediction has missed again. C++ 23 was officially published in October 2024 as ISO/IEC 14882:2024, and C++ 26 is hitting its final milestones toward ratification in 2026. A huge new feature called Reflection (P2996) is landing, Senders/Receivers (P2300) is becoming the standard async model, and Linear Algebra (P1673) is entering std.

Meanwhile the field is busier than ever. Game engines — Unreal 5.5, Unity's native core, CryEngine, in-house engines — are still C++. HFT (High-Frequency Trading) systems that trade in microseconds are still C++. Browser engines like Chromium, Firefox, and WebKit; compilers like LLVM, GCC, and Clang; databases like MySQL, PostgreSQL, and ClickHouse; GPU runtimes like CUDA, ROCm, and oneAPI — all C++. Almost every device and game shipped by Samsung, LG, Sony, Capcom, and NCSoft runs on top of it.

This post lays out the C++ of 2026 in one map. Standards (C++ 23 / 26), build tools (CMake 3.30, Meson, xmake, build2, Bazel), package managers (Conan 2, vcpkg), compilers (Clang 19, GCC 14, MSVC), standard library (libc++ vs libstdc++), sanitizers, and the successor-language candidates (Carbon, Hylo, Cppfront). It ends with how Korea and Japan actually ship products on top of all this.

1. C++ in 2026 — C++ 23 published, C++ 26 wrapping up

First the big picture.

C++ 23 — published October 2024

C++ 23 was officially published in October 2024 as ISO/IEC 14882:2024, three years after C++ 20 in 2020. The headline features:

- `std::expected<T, E>` — monadic error handling, similar to Rust's `Result`. The new baseline for exception-free codebases.

- `std::print` / `std::println` — taking over the 30-year-old territory of `printf` and iostream. The result of standardizing the `{fmt}` library.

- `std::generator` — coroutine-based lazy ranges. Python's `yield` pattern lands in std.

- `std::flat_map` / `std::flat_set` — cache-friendly associative containers backed by sorted `vector`.

- `std::mdspan` — non-owning multidimensional view, for BLAS and scientific computing.

- `[[assume(expr)]]` — optimizer hint.

- `if consteval` — compile-time branch.

- `static operator()` — strip the `this` capture overhead from lambdas.

- Deducing `this` — explicit object parameter on member functions.

C++ 26 — ratification in 2026, real star is Reflection

C++ 26 is expected to finish ratification in 2026 and be published as ISO/IEC 14882:2026 (feature-complete was declared at the Sofia meeting in June 2025). The core features:

- **Reflection (P2996)** — compile-time reflection and splicing. Rewrites C++ metaprogramming from scratch.

- **Senders/Receivers (P2300)** — the async model entering as std::execution. Successor to `std::future`.

- **Linear Algebra (P1673)** — a BLAS-shaped interface in std.

- **Hazard pointers / RCU** — memory reclamation for lock-free data structures.

- **Contracts (P2900)** — function pre/post conditions. Pulled from C++ 20 and finally back in.

- **Pattern matching (P2688)** — built on the `inspect` keyword.

- **`std::simd`** — data-parallel type.

Why C++ refuses to die — market reality

As of 2026, C++ stays in the 1-to-5 range of TIOBE and IEEE Spectrum rankings, and the GitHub PR stats agree. The reasons are simple.

1. **The legacy is enormous.** Chromium, LLVM, parts of Linux, MySQL, Unreal — all huge C++ projects, and moving them is effectively impossible.

2. **There is no full replacement.** Rust is excellent but does not cover every C++ niche (games, scientific computing, Windows GUI especially). Carbon is still alpha. Hylo is research.

3. **It is still fast.** Code generated by GCC 14 and Clang 19 remains world-class. Combined with LTO, PGO, and BOLT, it matches or beats other compiled languages.

4. **The standard is alive.** C++ 23 and 26 are not cleanups — they add real new features.

2. C++ 23 (October 2024) — std::expected / std::print / std::generator

Three of the most used C++ 23 features.

std::expected — monadic error handling

Rust's `Result<T, E>` has arrived in C++. `std::expected<T, E>` holds either a success value T or an error value E. A pattern long hand-rolled by exception-free codebases (games, embedded, HFT) is now standard.

#include <expected>

#include <string>

#include <print>

enum class ParseError { InvalidFormat, Overflow };

std::expected<int, ParseError> parse_int(std::string_view s) {

if (s.empty()) return std::unexpected(ParseError::InvalidFormat);

int v = 0;

for (char c : s) {

if (c < '0' || c > '9') return std::unexpected(ParseError::InvalidFormat);

if (v > (INT_MAX - (c - '0')) / 10) return std::unexpected(ParseError::Overflow);

v = v * 10 + (c - '0');

}

return v;

}

int main() {

auto r = parse_int("42")

.and_then([](int v) -> std::expected<int, ParseError> { return v * 2; })

.transform([](int v) { return v + 1; });

if (r) std::println("ok: {}", *r);

else std::println("err");

}

The monadic combinators `and_then`, `transform`, and `or_else` make chaining natural. Game-engine asset loaders, HFT order parsers, and embedded config parsers switched almost immediately.

std::print / std::println — successor to printf

The `{fmt}` library (Victor Zverovich) entered C++ 20 as `<format>`, and C++ 23 finally added the output functions `std::print` / `std::println`. It combines printf's format-string ergonomics with iostream's type safety.

#include <print>

#include <vector>

int main() {

std::println("hello {}, you are {} years old", "yj", 33);

std::vector<int> v{1, 2, 3, 4, 5};

std::println("vec = {}", v); // [1, 2, 3, 4, 5]

// Korean / Japanese render cleanly (UTF-8)

std::println("ko: {}, ja: {}", "annyeong", "konnichiwa");

}

In benchmarks `std::print` beats `printf` and clobbers `std::cout << ...` (no locale or sync overhead). As of 2026, iostream is effectively deprecated in style.

std::generator — coroutine-based lazy range

C++ 20 added the coroutine keywords (`co_await`, `co_yield`, `co_return`), but without a standard-library generator they were almost unused. C++ 23 added `std::generator<T>`, and Python's `yield` pattern now reads naturally in C++.

#include <generator>

#include <print>

#include <ranges>

std::generator<int> fib() {

int a = 0, b = 1;

while (true) {

co_yield a;

auto t = a + b;

a = b;

b = t;

}

}

int main() {

for (int v : fib() | std::views::take(10)) {

std::println("{}", v);

}

}

Combined with Ranges it is extremely powerful (next section).

3. C++ 26 — the age of Reflection

The biggest event in C++ 26 is **Reflection (P2996)**. Years of work by Daveed Vandevoorde, Wyatt Childers, Andrew Sutton, and Faisal Vali finally lands a static-reflection proposal in the standard.

It has the potential to replace SFINAE, much of `<type_traits>`, and the entire macro-based metaprogramming culture at once. The core is two new operators, `^^` and `[: ... :]`.

- `^^X` — obtains the reflection value of X (typed `std::meta::info`).

- `[: r :]` — splices the reflection value r back into the program as the original entity.

#include <meta>

#include <print>

struct Person {

std::string name;

int age;

std::string email;

};

template<typename T>

void print_struct(const T& t) {

constexpr auto members = std::meta::nonstatic_data_members_of(^^T);

template for (constexpr auto m : members) {

std::println("{} = {}",

std::meta::identifier_of(m),

t.[:m:]);

}

}

int main() {

Person p{"yj", 33, "yj@example.com"};

print_struct(p);

// name = yj

// age = 33

// email = yj@example.com

}

This one feature lets JSON serializers, ORMs, RPC stubs, GUI bindings, and configuration loaders be rewritten short and safe — without macros, without boost.pfr, without cereal. Clang trunk and EDG (Intel) have partial implementations as of late 2026.

Other big C++ 26 items:

- **`std::simd`** — SIMD as a standard type. Portable data-parallel code without intrinsics.

- **Contracts (P2900)** — `pre(expr)` and `post(expr)` for function pre/post conditions. Pulled from C++ 20 and finally back.

- **Pattern matching (P2688)** — `inspect (x) { ... }`, similar to Rust's `match`.

- **Hazard pointers / RCU** — reclamation techniques for lock-free data structures.

4. Modules — finally usable?

Modules entered C++ 20 but were nearly unusable from 2020 to 2023. Compiler implementations (Clang, MSVC, GCC) were incomplete, and integration with build systems (CMake, Bazel) was poor. From 2024 onward this changed quickly. As of 2026, **Modules are finally production-grade**.

Module basics

The classic header-based model (`#include`) is text preprocessing — the same header gets re-parsed in every .cpp, macros leak, ODR violations creep in, and builds are slow. Modules build the compiled interface once and import it everywhere.

// math.cppm (module interface)

export module math;

export int add(int a, int b) {

return a + b;

}

export int sub(int a, int b) {

return a - b;

}

// main.cpp

int main() {

std::println("{}", add(1, 2));

}

Build tool side

- **CMake 3.30 (2024)** — first-class C++ 20 modules support. Needs Ninja 1.11+.

- **MSVC (Visual Studio 17.10+)** — most stable modules implementation.

- **Clang 17–19** — modules nearly complete. Use standard `-std=c++20` + `-fmodules`, not `-fmodules-ts`.

- **GCC 14–15** — partial modules; header units still weak.

- **Bazel** — `cc_module` rule formalized in 2025.

Effects

- Build time — Chromium's partial modules conversion cut incremental builds by 30–50%.

- ODR — macros inside a module do not leak.

- IDE — once IntelliSense or clangd understands modules, navigation gets faster.

Pitfalls

- `import std` support is uneven across compiler-and-STL combinations. As of 2026, libc++ + Clang 18+ is OK, libstdc++ + GCC 14 is partial, and MSVC STL is OK.

- The build system has to compute module dependencies precisely. `cmake --build` has to scan the module graph before compiling, so first builds can actually be slower.

5. Ranges (C++ 20) — finally mature

Ranges entered C++ 20 but were barely used at first. Compile errors were terrifying (dozens of lines of template instantiation), debugger types were ugly, and the standard library was missing pieces. C++ 23 filled the gaps, and as of 2026 a meaningful chunk of everyday code is written with Ranges.

#include <ranges>

#include <vector>

#include <print>

int main() {

std::vector<int> v{1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

auto result = v

| std::views::filter([](int x) { return x % 2 == 0; })

| std::views::transform([](int x) { return x * x; })

| std::views::take(3);

for (int x : result) std::println("{}", x);

// 4

// 16

// 36

}

What C++ 23 added

- `std::views::enumerate` — same as Python's `enumerate`.

- `std::views::zip` / `zip_transform`.

- `std::views::join_with` — like a string join.

- `std::views::chunk` / `chunk_by` / `slide` — windowing.

- `std::views::stride` — step by n.

- `std::views::cartesian_product` — all combinations.

- `std::ranges::to<vector>` — materialize a view into a container.

auto names = std::vector<std::string>{"alice", "bob", "charlie"};

auto ages = std::vector<int>{30, 25, 40};

for (auto [name, age] : std::views::zip(names, ages)) {

std::println("{}: {}", name, age);

}

Performance

Ranges are lazy, so no intermediate vectors are allocated. If the compiler inlines well, generated code matches a hand-written for-loop (check godbolt). STL views do have pitfalls around reference invalidation, so materializing early with `std::ranges::to` is often the safer move.

6. Senders/Receivers (P2300) — the async model

`std::future` arrived in C++ 11 and was barely used. Promise/future cost was high, composition was missing, cancellation was absent, and the allocator was hardcoded. C++ 26's **Senders/Receivers (P2300)** redesigns all of that.

The model has been refined by Eric Niebler, Lewis Baker, Kirk Shoop, and Lee Howes inside production code at NVIDIA, Meta, and Microsoft (stdexec, libunifex).

Core concepts

- **Sender** — a lazy description that will eventually produce a value.

- **Receiver** — the sink that takes a sender's outcome.

- **Scheduler** — decides where a sender runs (thread pool, GPU stream, etc).

#include <execution>

#include <print>

namespace ex = std::execution;

int main() {

auto pool = ex::static_thread_pool(4);

auto sched = pool.get_scheduler();

auto work = ex::schedule(sched)

| ex::then([] { return 42; })

| ex::then([](int x) { return x * 2; });

auto [result] = std::this_thread::sync_wait(work).value();

std::println("result = {}", result); // 84

}

Why it matters

The old `std::async` either created a thread directly or let the launcher decide — you did not know where it would run. With Senders the **scheduler is explicit**, so the same code runs on a thread pool, fibers, a GPU stream, Linux io_uring, Windows IOCP, or an Android JNI thread.

Composition is also natural: `then`, `when_all`, `let_value`, `upon_error`, `stopped_as_optional` build async graphs. Cancellation propagates via `stop_token`.

Some of NVIDIA's CUDA 12 and 13 async APIs already expose a sender interface, and a standard implementation should land in late 2026.

7. Linear algebra BLAS std (C++ 26)

Another big C++ 26 feature is **`std::linalg` (P1673)** — Bradley A. Lucier, Mark Hoemmen, Christian Trott, and Daisy Hollman led the standardization of a BLAS-shaped interface.

For decades C++ linear algebra relied on external libraries (Eigen, Blaze, Armadillo, xtensor). Every project wrapped the same BLAS calls a different way, code portability was poor, and the rise of ML/AI made the lack of a standard increasingly painful.

`<linalg>` sits on top of `std::mdspan` (C++ 23) and exposes a standard interface to BLAS Level 1, 2, and 3.

#include <linalg>

#include <mdspan>

#include <vector>

int main() {

std::vector<double> data(16);

auto A = std::mdspan(data.data(), 4, 4);

std::vector<double> x(4, 1.0);

std::vector<double> y(4, 0.0);

// y = alpha * A * x + beta * y

std::linalg::matrix_vector_product(

A, x, y);

}

The backend implementation is up to the vendor (Intel MKL, OpenBLAS, NVIDIA cuBLAS, AMD rocBLAS). Only the standard interface is fixed.

Expect a meaningful shift in ML inference, simulation, computer vision, and signal processing.

8. CMake 3.30 / Meson / xmake / build2 / Bazel C++ — build tools

The eternal headache of C++. The 2026 build-tool landscape:

CMake — de facto standard

Love it or hate it, CMake is the de facto standard. Nearly every library integrates via `find_package` or `FetchContent`, and every IDE (CLion, Visual Studio, Qt Creator, VS Code) supports it.

- **CMake 3.30 (2024)** — first-class C++ 20 modules, presets v8, new `cmake -E` subcommands.

- **CMake 3.31 / 3.32** — module support polished, package manifest (vcpkg / Conan) integration improved.

The basic pattern:

cmake_minimum_required(VERSION 3.30)

project(myapp CXX)

set(CMAKE_CXX_STANDARD 23)

set(CMAKE_CXX_STANDARD_REQUIRED ON)

set(CMAKE_CXX_EXTENSIONS OFF)

add_executable(myapp src/main.cpp)

find_package(fmt CONFIG REQUIRED)

target_link_libraries(myapp PRIVATE fmt::fmt)

CMake's downsides are well known — awkward DSL, ugly error messages, generator expressions get hairy in large projects. But **everyone knows it**, which is the killer feature.

Meson — the Pythonic alternative

Meson is a Python-implemented build system with clean syntax and fast builds. GNOME, systemd, QEMU, and GStreamer use it. Faster than CMake (Ninja backend by default) with great subproject support.

project('myapp', 'cpp',

default_options : ['cpp_std=c++23'])

fmt_dep = dependency('fmt')

executable('myapp', 'src/main.cpp', dependencies : fmt_dep)

The downside is library support — not as broad as CMake. But in GNOME-land it is effectively the standard.

xmake — Lua-based emerging contender

xmake is a Lua-based build system from China, very fast and modern (`xmake init` → `xmake build` → `xmake install`). It bundles a package manager (`xrepo`). Adoption is growing fast in games and embedded.

add_rules("mode.debug", "mode.release")

set_languages("c++23")

target("myapp")

set_kind("binary")

add_files("src/*.cpp")

add_packages("fmt")

build2 — academic / strict alternative

build2 is a strict, consistent build system + package manager. C++ Modules support is the fastest and most correct here. Small user base but a passionate one.

Bazel — Google-style monorepo

Bazel is the open-source release of Google's internal Blaze. It shines in massive monorepos (TensorFlow, gRPC, Envoy) thanks to hermetic builds, remote cache, and distributed execution. Downside: steep learning curve and overkill setup for small projects.

BUILD.bazel

cc_binary(

name = "myapp",

srcs = ["src/main.cpp"],

copts = ["-std=c++23"],

deps = ["@fmt//:fmt"],

)

As of 2026 the google/bazel-cpp modules support has landed.

Rough selection guide

- General open source / library → CMake.

- GNOME / systemd ecosystem, fast builds → Meson.

- Games, embedded, Chinese ecosystem, Lua-friendly → xmake.

- Want the best modules support → build2.

- Monorepo, tens of thousands of targets, remote cache → Bazel.

9. Conan 2 / vcpkg — package managers

For decades C++'s biggest weakness was the lack of a package manager. Everyone built from source, leaned on the distro, or used git submodules. In the 2020s two big players settled in — **Conan** and **vcpkg**.

Conan 2 (major release 2023)

Conan is a Python-based distributed package manager, backed by JFrog. Conan 2 was a clean rewrite of 1.x and is very stable as of 2026.

conanfile.py

from conan import ConanFile

from conan.tools.cmake import CMake, cmake_layout

class MyAppRecipe(ConanFile):

settings = "os", "compiler", "build_type", "arch"

generators = "CMakeDeps", "CMakeToolchain"

def requirements(self):

self.requires("fmt/10.2.1")

self.requires("spdlog/1.13.0")

self.requires("nlohmann_json/3.11.3")

def layout(self):

cmake_layout(self)

conan install . --build=missing

cmake --preset conan-default

cmake --build --preset conan-release

Conan's strength is its **profile** system. It builds the same package with different settings (debug/release, GCC/Clang, x86/arm, libc++/libstdc++) and caches each. Pair it with an internal Artifactory to share patched in-house builds.

vcpkg (Microsoft, 2017–)

vcpkg is Microsoft's manager. Originally Windows-centric, it now handles Linux and macOS well. The catalog is huge (3000+ libraries) and CMake integration is natural.

// vcpkg.json

{

"name": "myapp",

"version": "0.1.0",

"dependencies": [

"fmt",

"spdlog",

"nlohmann-json"

]

}

vcpkg install

cmake -B build -S . \

-DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake

cmake --build build

vcpkg's strength is manifest mode plus binary cache. Dependencies are not rebuilt every time — they come from the cache. Integration with Azure DevOps and GitHub Actions is solid.

Conan vs vcpkg — how to choose

| Criterion | Conan 2 | vcpkg |

|-----------|---------|-------|

| Origin | JFrog (Spain) | Microsoft |

| Language | Python recipes | CMake-flavored portfile |

| Profiles | Very strong | Weak (triplet-based) |

| Catalog | 1500+ | 3000+ |

| In-house cache | Artifactory-friendly | Azure Artifacts |

| Learning curve | Steep | Gentle |

| Windows | OK | Best |

Roughly: **internal build matrix complexity** → Conan. **Quick start, Windows primary** → vcpkg.

10. Clang 19 / GCC 14 / MSVC — compilers

State of the major compilers as of May 2026.

Clang 19–20 (LLVM)

- C++ 23 nearly complete; about half of C++ 26 (modules, reflection trunk).

- Fastest compile speed and best diagnostics.

- Pairs best with libc++.

- De facto standard for macOS, iOS, and Android (NDK).

- Apple Clang lags LLVM trunk by one or two versions.

GCC 14–15

- C++ 23 nearly complete; C++ 26 catching up quickly.

- De facto standard for Linux servers and embedded.

- Ships with libstdc++. Most trusted standard library quality.

- `-O3` code quality is often slightly ahead of Clang (benchmark-dependent).

MSVC (Visual Studio 17.10+)

- De facto standard for Windows desktop, consoles (Xbox), and games (Unreal).

- Used to lag the standard through the 2010s; now fast.

- Frequently the first to ship modules and coroutines.

- C++ standard library (MSVC STL) is open source on GitHub (microsoft/STL).

Selection guide

| Environment | First choice |

|-------------|--------------|

| Linux server | GCC 14 |

| macOS / iOS | Apple Clang (or Homebrew LLVM) |

| Windows desktop / games | MSVC |

| Android NDK | Clang |

| Embedded ARM | GCC arm-none-eabi or Clang |

| HFT / latest standards | Clang trunk |

11. libc++ vs libstdc++ — the standard library

The C++ standard library is **just the standard — implementations are separate**. The major implementations as of 2026:

- **libstdc++** — GCC camp. Most conservative, very complete. De facto standard on Linux.

- **libc++** — LLVM camp. Standard on macOS and iOS. Growing on Linux.

- **MSVC STL** — Microsoft's. Standard on Windows. Open source on GitHub.

Differences

- ABI — libstdc++ and libc++ are **not ABI-compatible**. Mixing object files breaks (especially `std::string` and `std::list`).

- Performance — algorithm performance differs (e.g. `std::sort`, `std::regex`). libc++'s `std::regex` is faster in many benchmarks; libstdc++'s `<algorithm>` is often more optimized.

- Standard catch-up — libc++ usually implements new features faster.

- Modules — as of 2026, libc++ + Clang 18+ has the most stable `import std`. libstdc++ + GCC 14 is partial; MSVC STL is OK.

Choosing

On Linux the choice mostly follows the distro and default compiler. macOS is effectively libc++. If you want to pick deliberately, use Clang with `-stdlib=libc++`.

12. Sanitizers — ASan / UBSan / TSan / MSan

Sanitizers are runtime detectors for memory and concurrency bugs, started by LLVM and followed by GCC. They raised the bar for C++ code quality.

AddressSanitizer (ASan)

- What — heap-buffer-overflow, use-after-free, use-after-return, double-free, leaks.

- Overhead — 2–3x CPU, 1.5–3x memory.

- Use — `-fsanitize=address -fno-omit-frame-pointer`.

clang++ -std=c++23 -O1 -g -fsanitize=address -fno-omit-frame-pointer main.cpp

ASAN_OPTIONS=detect_leaks=1 ./a.out

Running every test under ASan in CI is the 2026 baseline.

UndefinedBehaviorSanitizer (UBSan)

- What — signed integer overflow, null deref, divide by zero, misaligned access, and more.

- Overhead — close to zero.

- Use — `-fsanitize=undefined`.

Combines cleanly with ASan.

ThreadSanitizer (TSan)

- What — data races, some deadlocks, mutex misuse.

- Overhead — 5–15x CPU, 5–10x memory.

- Use — `-fsanitize=thread`.

For multi-threaded code, TSan is essentially the only automatic race detector.

MemorySanitizer (MSan)

- What — uninitialized memory reads.

- Overhead — about 3x CPU.

- Caveat — the standard library has to be built with MSan too to avoid false positives (use the MSan build of libc++).

Recommended setup

- Add an ASan + UBSan matrix to CI.

- Run TSan for multi-threaded code in a separate job.

- Run a fuzzer (libFuzzer + ASan) nightly.

13. Successor languages — Carbon (Google) / Hylo / Cppfront (Herb Sutter)

Three big attempts to answer "how do we escape C++'s ABI burden, unsafe defaults, and giant standard?".

Carbon (Google, 2022–)

Google's C++ successor language, led by Chandler Carruth. The core idea is **bidirectional interop** — mixing C++ and Carbon in the same codebase, the way Swift related to Objective-C.

package Sample api;

fn Fib(n: i32) -> i32 {

if (n < 2) { return n; }

return Fib(n - 1) + Fib(n - 2);

}

fn Main() -> i32 {

Print("fib(10) = {0}", Fib(10));

return 0;

}

As of May 2026, Carbon is still 0.x experimental. Not self-hosting, almost no standard library, not recommended for general use. **The official position is that production use will not happen before 2030.**

Hylo (formerly Val, 2020–)

A research language by Dimitri Racordon and Dave Abrahams. Less of a C++ successor and more a serious exploration of **mutable value semantics**. Variables are unique by default and mutation is explicit, eliminating race and aliasing issues.

A more radical version of some Swift ideas. Still research, but getting attention from academia and industry.

Cppfront / cpp2 (Herb Sutter, 2022–)

From Herb Sutter, former chair of the C++ standards committee — **"alternative syntax for C++"**. Not a separate language: cppfront takes cpp2 code and transpiles it to C++.

// hello.cpp2

main: () = {

print("hello, world!");

}

square: (x: int) -> int = x * x;

You can freely mix with existing C++ and get safe defaults (default const, bounds checking) for free. A much lighter-touch approach than Carbon.

Summary

All C++ successor languages in 2026 are still **prototype / experimental**. One or two may settle in over the next 5–10 years, but C++ itself keeps evolving in the meantime — once Reflection, Senders, and Modules are widely used, reasons to leave shrink.

**Rust** is the most common alternative in practice. It directly competes with C++ in systems, embedded, and OS work (Rust modules in the Linux kernel, parts of Windows kernel, parts of Android). But games, scientific computing, Windows GUI, and large legacy codebases stay overwhelmingly C++.

14. Korea — Samsung, LG, NCSoft, Toss infra

Where C++ runs in Korea.

Samsung Electronics

- **System LSI / Foundry** — parts of chip design tooling (EDA) in C++.

- **Mobile (formerly IM)** — Android native layer, camera ISP firmware, modem firmware.

- **CE (consumer electronics)** — Tizen OS on TVs, embedded controllers in fridges and washing machines.

- **Semiconductor** — memory controller verification (SystemVerilog + C++), DRAM/NAND firmware.

- **Samsung Research** — parts of AI/ML, on-device LLM inference engines.

LG Electronics

- **HE (TV)** — webOS native components, picture-quality engine.

- **VS (automotive)** — vehicle infotainment, autonomous driving SoC firmware.

- **H&A (home appliances)** — washing machines, ACs, robot vacuums.

NCSoft

- **Lineage / Blade & Soul** — in-house engines (custom C++).

- **TL (Throne and Liberty)** — Unreal Engine 5 + custom C++.

- **AI Center** — Vapor (in-house game AI), TTS engines.

Toss — infra / trading

- **Toss Securities — matching engine** — C++ in some latency-critical paths (Java/Kotlin is the main stack, but parts of the matching core run on C++).

- **Infra — some middleware**.

(Note: Toss's main services are Kotlin and C++ usage is limited, but there are real cases in latency-critical pieces.)

Other Korean companies

- **Kakao Entertainment** — parts of game servers and multimedia processing.

- **Krafton** — PUBG client (Unreal Engine 4 + custom), server-side battle simulator.

- **Pearl Abyss** — Black Desert's in-house engine BlackSpace (C++).

- **Smilegate** — Lost Ark client (Unreal), in-house server engine.

- **Hyundai / Mobis** — vehicle ECU firmware, ADAS.

- **Hanwha Systems / LIG Nex1** — defense embedded.

Korean C++ community

- **Modern C++ Korea** — Facebook group plus meetups. Korean National Body activity in the standards committee.

- **NDC (NEXON Developers Conference)** — game developer conference with many C++ talks.

- **Books / translations** — books by Chanho Ok, Sangsoo Park and others are widely read.

15. Japan — Sony PlayStation, Square Enix, Capcom, Bandai Namco

Japan is the homeland of games, consumer electronics, and automotive — and almost everything runs on top of C++.

Sony Interactive Entertainment

- **PlayStation 5 / Pro / 6** — almost the entire OS, SDK, and devkit is C++. Firmware is C plus C++.

- **PSN backend** — partly C++, partly Java/Kotlin/Rust.

- **First-party studios** — Naughty Dog, Insomniac, Santa Monica, Polyphony, Guerrilla — all in-house engines or Unreal plus C++.

Square Enix

- **Crystal Tools / Luminous Engine** — Final Fantasy series engines. All C++.

- **Dragon Quest** — Unreal Engine or in-house.

- **External licensing** — many titles on Unreal Engine 5.

Capcom

- **RE Engine** — starting with Resident Evil 7. Devil May Cry 5, Monster Hunter Rise / Wilds, Street Fighter 6 all run on RE Engine. Custom C++.

- **MT Framework (older)** — some legacy.

Bandai Namco

- **Tekken 8** — Unreal Engine 5.

- **Elden Ring — FromSoftware** — in-house Souls engine. C++.

- **Gundam series** — Unreal or in-house.

Konami

- **eFootball / Winning Eleven** — Unreal Engine.

- **Momotaro Dentetsu** — in-house.

SEGA

- **Phantasy Star Online** — in-house.

- **Yakuza / Like a Dragon** — Dragon Engine (in-house C++).

Japanese automotive (Toyota, Honda, Nissan)

- **Vehicle ECU / Autosar** — almost all C++ or C. Autosar Adaptive is C++ based.

- **ADAS / autonomous driving** — C++ main. Parts of ROS (ROS 2 is C++).

Japanese consumer electronics (Sony, Panasonic, Sharp)

- **TVs / cameras / audio** — embedded Linux plus C++, or RTOS plus C++.

Japanese C++ community

- **CppCon Japan / C++ MIX** — Tokyo and Osaka meetups.

- **C++ Japan NB** — active Japanese representatives on the standards committee.

- **Cybozu / DeNA / GREE** — C++ in parts of their backends.

16. Who should pick C++ — games / embedded / HFT / systems

Where to choose C++ for a new project in 2026, and where not to.

When C++ is the right answer

1. **Games — Unreal Engine or in-house engine** — almost no other choice. Even Unreal gameplay code is C++ (or Blueprint).

2. **HFT (High-Frequency Trading)** — microsecond latency budgets. The JVM's GC is a non-starter here.

3. **OS / systems programming (partial)** — Linux kernel is mostly C plus some Rust, but parts of Windows kernel, parts of Apple Darwin, and embedded RTOSes still use a lot of C++.

4. **Embedded / firmware** — ARM Cortex-M, RISC-V, automotive ECUs, consumer electronics — C++ or C.

5. **CAD / simulation / EDA** — AutoCAD, SolidWorks, ANSYS, Synopsys, Cadence are almost entirely C++.

6. **Database engines** — MySQL, PostgreSQL, ClickHouse, MongoDB, RocksDB.

7. **Compilers / runtimes** — LLVM, GCC, V8, JVM HotSpot itself.

8. **Graphics / GPU runtimes** — CUDA, ROCm, oneAPI, Vulkan implementations.

9. **AI inference engines** — llama.cpp, PyTorch C++ runtime, TensorFlow Lite, ONNX Runtime.

When Rust is probably better

1. **New systems programming projects** (especially memory-safety-critical) — Rust.

2. **WebAssembly targets** — Rust is far more natural.

3. **Internet infrastructure (Cloudflare, Discord, etc.)** — Rust is effectively the standard.

4. **CLI tools** — Go or Rust.

When Go / Java / TypeScript is the answer

1. **Backend API servers** — Go / TypeScript / Java / Kotlin.

2. **Data pipelines** — Python / Scala / Java.

3. **GUI desktop apps** — Electron / TypeScript / C# (WPF). Games stay on C++.

Pitfalls

- If "safety" is not an absolute requirement, productivity in modern C++ (20 / 23 / 26) is not bad either. `std::expected`, `std::print`, Ranges, and Modules genuinely change daily life.

- Adding features to an existing C++ codebase — almost always stay on C++. Rust interop is possible but ABI, build, and CI all get more complex.

- Learning curve — modern C++ is still steep. Rust is known to be hard, but nothing matches C++'s UB plus template metaprogramming.

17. Closing — modern C++ is still alive

The C++ of 2026 is not the C++ of 1998 nor the C++ of 2011. C++ 23's `std::expected`, `std::print`, and `std::generator` have changed everyday code, and C++ 26's Reflection, Senders, and Linear Algebra will rewrite the library ecosystem. Modules finally lighten builds, and Ranges make code readable.

Build tools span CMake 3.30, Meson, xmake, build2, and Bazel — pick one. Both Conan 2 and vcpkg are production-ready. Clang 19, GCC 14, and MSVC are all nearly C++ 23 complete. Sanitizers are now the baseline for quality.

The successor languages — Carbon, Hylo, Cppfront — are all interesting but still prototypes. Rust has taken some territory but cannot take all of it. In games, embedded, HFT, and systems, C++ remains dominant, and the giant companies of Korea and Japan keep building their next products on top of it.

"C++ is dead" missed again. And it will keep missing every year. Meanwhile, C++ itself keeps getting better.

References

ISO standards / committee papers

- ISO/IEC 14882:2024 — Programming languages — C++ — [https://www.iso.org/standard/83626.html](https://www.iso.org/standard/83626.html)

- WG21 (C++ standards committee) — [https://www.open-std.org/jtc1/sc22/wg21/](https://www.open-std.org/jtc1/sc22/wg21/)

- P2300R10 — std::execution (Senders/Receivers) — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2300r10.html](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2300r10.html)

- P2996 — Reflection for C++26 — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2996r4.html](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2996r4.html)

- P1673 — A free function linear algebra interface based on the BLAS — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1673r13.html](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1673r13.html)

- P2900 — Contracts for C++ — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2900r6.pdf](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2900r6.pdf)

Reference / learning

- cppreference — [https://en.cppreference.com/](https://en.cppreference.com/)

- Compiler Explorer (godbolt) — [https://godbolt.org/](https://godbolt.org/)

- C++ Core Guidelines — [https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)

Compilers / standard libraries

- LLVM / Clang — [https://llvm.org/](https://llvm.org/)

- GCC — [https://gcc.gnu.org/](https://gcc.gnu.org/)

- MSVC STL (open source) — [https://github.com/microsoft/STL](https://github.com/microsoft/STL)

- libc++ — [https://libcxx.llvm.org/](https://libcxx.llvm.org/)

- libstdc++ — [https://gcc.gnu.org/onlinedocs/libstdc++/](https://gcc.gnu.org/onlinedocs/libstdc++/)

Build tools

- CMake — [https://cmake.org/](https://cmake.org/)

- Meson — [https://mesonbuild.com/](https://mesonbuild.com/)

- xmake — [https://xmake.io/](https://xmake.io/)

- build2 — [https://build2.org/](https://build2.org/)

- Bazel — [https://bazel.build/](https://bazel.build/)

Package managers

- Conan — [https://conan.io/](https://conan.io/)

- vcpkg — [https://vcpkg.io/](https://vcpkg.io/)

Sanitizers

- AddressSanitizer — [https://clang.llvm.org/docs/AddressSanitizer.html](https://clang.llvm.org/docs/AddressSanitizer.html)

- UndefinedBehaviorSanitizer — [https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html)

- ThreadSanitizer — [https://clang.llvm.org/docs/ThreadSanitizer.html](https://clang.llvm.org/docs/ThreadSanitizer.html)

- MemorySanitizer — [https://clang.llvm.org/docs/MemorySanitizer.html](https://clang.llvm.org/docs/MemorySanitizer.html)

Successor / experimental languages

- Carbon — [https://github.com/carbon-language/carbon-lang](https://github.com/carbon-language/carbon-lang)

- Hylo — [https://www.hylo-lang.org/](https://www.hylo-lang.org/)

- Cppfront — [https://github.com/hsutter/cppfront](https://github.com/hsutter/cppfront)

Libraries / projects

- fmt (origin of std::format / std::print) — [https://github.com/fmtlib/fmt](https://github.com/fmtlib/fmt)

- stdexec (NVIDIA reference for Senders) — [https://github.com/NVIDIA/stdexec](https://github.com/NVIDIA/stdexec)

- mdspan (reference implementation) — [https://github.com/kokkos/mdspan](https://github.com/kokkos/mdspan)

Korean and Japanese games / engines

- Unreal Engine — [https://www.unrealengine.com/](https://www.unrealengine.com/)

- Capcom RE Engine — [https://www.capcom-games.com/re-engine/](https://www.capcom-games.com/re-engine/)

- NCSoft — [https://kr.ncsoft.com/](https://kr.ncsoft.com/)