In Defense of C++

Modern C++ Safety and Footguns

• Some argue “modern C++” (smart pointers, STL, sanitizers, contracts) has significantly reduced traditional footguns.
• Others counter that new features (capturing lambdas, string_view, iterator invalidation, std::array without bounds checks) introduce fresh, subtle lifetime and memory hazards.
• Debate over std::array and unchecked operator[] becomes a proxy for priorities: compatibility/perf vs. safety-by-default. Contracts in C++26 are viewed as both welcome and comically late.
• Several note that in C/C++, warnings must be treated as errors; tools (sanitizers, static analyzers) are essential, not optional.

Rust vs. C++ (Performance, Safety, and DX)

• Strong disagreement with the article’s claim that Rust is only a “small part” of improved safety in C++→Rust rewrites. Many state memory safety is exactly where Rust shines and that “just rewriting” in any language does not explain the observed reduction in bugs.
• Some C++ users prefer “performance and stability” and complain about Rust’s fast evolution and breaking ecosystem. Others report the opposite: Rust’s compiler and ecosystem feel more stable and technically “excellent” than their C++ tooling.
• Consensus that Rust and C++ are broadly similar in raw performance, with Rust gaining advantages over time as it can evolve ABI and safety without legacy constraints.

Tooling, Build Systems, and Package Management

• Big fault line: C++’s fragmented build and dependency story (make/CMake/autotools/Conan/vcpkg/pkg-config/system package managers) vs. “one-command” experiences like Cargo/Gradle.
• Some defend Unix-style “many small tools” and system package managers as a feature (curation, flexibility, offline builds, distro integration).
• Others call this Stockholm syndrome: non‑portable build scripts, version conflicts, and “build engineers” maintaining fragile C++ builds are seen as a serious productivity and onboarding cost.
• Mixed views on vcpkg/Conan/CMake+find_package; CMake is widely acknowledged as de facto, but not loved.

Complexity, Readability, and Language Design

• Many argue you cannot safely ignore “advanced” C++: move semantics, templates, operator overloading, undefined behavior, and initialization rules leak into everyday code via the standard library.
• Others advocate a “C-with-RAII” subset: minimal templates, limited overloading, heavy use of STL containers, RAII, and smart pointers; but acknowledge team members will often use more exotic features anyway.
• C++ is described as “arcane” and “monumental”; memes about its iceberg of complexity resonate. Developer experience (slow compiles, cryptic template errors, header/ABI issues) is a recurring complaint.

Legacy, Domains, and Future Trajectory

• Broad agreement that C++ (and C) will remain entrenched for decades in OSes, game engines, embedded and high‑performance systems; rewrites are costly and risky.
• For new projects, many commenters strongly favor Rust or higher-level languages unless there is a clear need for C++’s specific ecosystem or cross‑platform reach.
• Some see C++ evolving into a “COBOL/Fortran of systems” role: important but shrinking for greenfield work, with safety and DX expectations moving elsewhere.