The C++ Killers (Not You, Rust)

C++ evolution, ABI, and standardization

• Several comments argue the C++ committee is constrained by a strong “no ABI breaks” stance, which blocks performance and library improvements (e.g., std types, intmax_t changes).
• Others note the standard doesn’t define an ABI, but acknowledge the committee has explicitly voted to avoid ABI breaks and that proposals are frequently rejected on that basis.
• This conservatism is contrasted with actual breaking changes, such as UTF‑8 literals switching to char8_t in C++20, forcing compilers to add opt‑out switches.

Safety, “leash” languages, and memory management

• One camp sees newer languages (Rust, Go, etc.) as valuable precisely because they constrain unsafe behavior and reduce cognitive load and bug classes (especially memory safety and security).
• Critics argue these languages overconstrain developers, reduce expressiveness, and represent “authoritarian” static guarantees; proponents respond that they’re just automated enforcement of widely agreed good practices, with explicit escape hatches.
• There’s debate over whether modern C++ already discourages manual memory management via RAII and smart pointers; some say it still leaves too many footguns compared with Rust’s default safety model.

Simplicity vs expressiveness

• Some assert simpler languages are inherently better; others push back that “simple” is ill‑defined and often just shifts burden to programmers.
• Examples are traded (C, Lisp, Python, Rust, C++) to argue that “less expressive” is often mistaken for “simpler,” and that hidden complexity (UB, implicit rules) makes C less simple than it appears.

C++’s role and long‑term prospects

• Multiple comments frame C++ as a “language of last resort” for bare‑metal, embedded, and high‑performance domains, with higher‑level languages taking over GUIs, desktop apps, and cloud systems.
• Some expect Rust and other niche systems languages to chip away at C++ in performance‑critical areas, but believe C/C++ will remain entrenched for decades due to existing codebases and ecosystems.

Undefined behavior and minutiae

• Discussion touches on uninitialized members, integer promotion rules (uint16_t arithmetic example), and how easy it is to introduce UB in C/C++.
• Participants disagree whether mastering such minutiae is a point of pride enabling precise control, or an unnecessary burden that harms overall software quality.

Article‑specific technical notes and side topics

• Commenters nitpick examples in the article (incorrect uint16_t expression, inefficient sine polynomial) and suggest known optimal techniques (Horner/Estrin).
• Brief mentions of tools and projects (Numba, Julia, Spiral, ForwardCom, Go memory ballast) illustrate broader interest in domain‑specific optimization and hardware‑aware code generation.