The post announces the public release of a documentary on C++, framed as a 40-year look at how “C with Classes” became one of the world’s most widely used programming languages. People who watched it called it enjoyable and well produced, and several appreciated seeing Stroustrup, Stepanov, Kernighan, Lattner, Alexandrescu, and others in one place. A recurring complaint was that the film is mostly reverent. It spends little time on the language’s failures until late, so it works better as oral history than as a hard critical account.
Most of the useful discussion was not about the movie but about why C++ spread and why it still survives. The consensus was that C++ won because it let teams extend C incrementally instead of replacing it. That compatibility let companies keep code, tools, and hiring pipelines while adding higher-level features. Several people argued that this same compromise also locked in decades of complexity. C++ today is less a single language than a federation of house styles, standards, banned features, custom containers, and build systems. That makes experienced users comfortable inside their chosen subset, but makes maintenance and onboarding expensive across codebases.
The comments were especially sharp on safety and ergonomics. Even people with long C++ careers said they prefer
Rust for new work because C++ makes undefined behavior and memory hazards too easy to ship, then asks tooling, testing,
Valgrind, and discipline to catch what the language itself permits. Others pushed back that this is survivable in practice because serious teams always define a restricted subset and coding style, and because C++ still gives unmatched reach from low-level control up through high-level abstraction in one toolchain. In games, embedded, browsers, compilers, and
AI-adjacent infrastructure, that flexibility still matters.
A second strong theme was that the pain is often in the ecosystem more than the core language. Build times, package management, module support, debug tooling, standard library tradeoffs, and compiler and
IDE fragmentation came up repeatedly. Some argued the standard library is “good enough” unless you have very specific performance needs. Others said performance-sensitive domains routinely avoid large chunks of it, especially around containers, because
ABI constraints and old design choices leave too much runtime cost, compile-time cost, or both. That split captures the overall landing point well: C++ is still everywhere important, still capable, and still historically fascinating, but many people now see it as a language to contain rather than embrace.