A decade-old 'use less C++' manifesto reignites the same fight: which subset, exactly?
Orthodox C++ argues for a minimal subset — no exceptions, no RTTI, no allocating STL, no iostream — that improves on C without modern C++'s machinery. Reposted for the fourth time in nine years, it detonates the same debate.
Embedded veterans call it a great list of what to avoid. Application programmers call it arbitrary hobbling — and one flags the manifesto's printf-over-streams advice as a memory-safety footgun, not a simplification.
The thread's truest line cuts past both camps: everyone agrees a clean subset of C++ exists, and no two engineers agree on which one. In 2026, the unspoken third option, Rust or Zig, hangs over the whole argument.
The manifesto: C++ minus most of C++
Branimir Karadžić's Orthodox C++ defines a deliberately small subset of the language: avoid exceptions, RTTI, memory-allocating STL containers, iostream and stringstream, heavy metaprogramming, and bleeding-edge standards (wait roughly five years before adopting them). Favor C-like code, C runtime headers, and printf-style I/O, in the spirit of Stroustrup's line about a smaller, cleaner language struggling to get out of C++. The argument is readability, broad compiler compatibility, and avoiding hidden costs. The post is 2016 vintage and has surfaced on HN repeatedly; each time it lights the same fuse.
Embedded says yes, applications say no
The clearest fault line is domain. To an engineer working close to the metal, the list is just hard-won taste:
"I've been doing embedded systems in C++ since rocks were young, and this is a great summary of what to avoid. I would sure love a good coroutine runtime, and first-class support for defer…" — a longtime embedded C++ developer
To someone building higher-level systems, the same rules read as needless self-mutilation — and the maintainer of the Ardour DAW didn't hold back:
"You can take
for (auto const & ess : esses) { ... }from my cold dead hands. Also, you can fight me if you want to takedynamic_cast… stick with C and leave C++ programmers alone. I haven't seen a less useful article about C++ in a long time." — the maintainer of the Ardour audio workstation
The advice that might be actively dangerous
One reader went further than taste, arguing the manifesto's signature recommendation inverts the safety case it claims:
"stringstreams and fmt are a godsend compared to printf/scanf, which have historically led to most memory bugs in the first place!… Anyone advocating the use of the old cstdio as a primary design decision… is not serious." — a reader on printf as a memory-safety footgun
The line that ends the argument
After all the back-and-forth, one comment compressed the entire genre of "use the good subset of C++" pieces into two sentences:
"Somewhere within c++ there is a subset of c++ that is a great language. The problem of course is that no one agrees on which subset that is." — a reader naming the actual impasse
Why it still flares in 2026
The reason this 2016 post keeps drawing 140-comment threads isn't that anyone's mind changes. It's that "Orthodox C++" names a real desire — a smaller, predictable language — without resolving the only hard question, which features make the cut, and that question has no domain-independent answer. What's different now is the exit nobody in the manifesto mentions: when the pitch is "C++ but disciplined enough to be safe and simple," Rust and Zig are standing in the room asking why you're still negotiating with the preprocessor at all.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
Ken Shirriff dissolved a 1980 Intel chip in acid to read its adder. The author took questions
The 8087 made math up to 100x faster than the CPU it shipped beside. Shirriff stripped the metal layer off the die to photograph the transistors of its 69-bit adder — the nanomachine at the chip's core.