I think C++ is still a desirable coding platform compared to Rust
Advocates of both C++ and Rust weigh in on whether C++ remains a preferable choice for new systems work, balancing C++’s maturity, performance, ecosystem, and larger talent pool against Rust’s stronger safety guarantees and more coherent tooling. Many argue that while disciplined C/C++ teams can avoid most memory bugs, this comes at a high productivity cost and still leaves room for subtle vulnerabilities, whereas Rust’s borrow checker, enums/pattern matching, error handling, and Cargo-based workflow catch whole classes of issues by construction. Others point out gaps and trade-offs in Rust—such as embedded and shared-library scenarios, binary size, ecosystem quality, and async complexity—concluding that Rust is steadily eroding C++’s domain but has not yet fully displaced it.
Language adoption & use cases
- Many commenters with long C++ backgrounds now default to Rust for new greenfield work and hobbies, citing productivity and safety; they still use C++ when required by legacy code, existing libraries, or company policy.
- Some stick firmly with C or C++ (including “modern C++”), arguing that with enough discipline, tooling, and testing, memory bugs are rare enough and Rust’s benefits are not compelling for them.
- There is agreement that C++ “isn’t going anywhere” due to its massive installed base, existing toolchains, and embedded/device coverage.
Tooling, build systems, and ecosystems
- Rust’s Cargo plus crates.io is widely praised as a major advantage: one standard build system, easy dependency management, straightforward cross-compilation.
- Others criticize crates.io as “npm-like”: many 0.x hobby crates, long dependency chains, multiple versions in one binary, lack of namespaces and moderation; some large orgs vendor and self-manage dependencies.
- C++’s fragmented build tooling (CMake, Bazel, custom systems) is seen as a major pain, though some argue that mature C++ build systems can be superior to Cargo in certain enterprise workflows.
Safety vs “discipline”
- One camp claims disciplined C/C++ teams with sanitizers, fuzzing, and strict practices can mostly avoid memory crashes; they downplay Rust’s safety as overvalued.
- Others counter that even elite C/C++ projects (kernels, browsers, databases) still ship memory vulnerabilities, and that silent memory corruption is far worse than occasional segfaults.
- Safety is framed as “preserving invariants,” with Rust’s type system and borrow checking reducing entire bug classes by construction.
Performance and optimization
- Some argue Rust’s defined overflow behavior and bounds checks impose nontrivial overhead, justifying C++’s undefined behavior for maximum optimization freedom.
- Others respond that:
- Rust offers checked/wrapping/saturating arithmetic primitives for explicit control.
- Compilers can often eliminate bounds checks.
- The typical overhead is small compared to the engineering cost of UB and memory bugs.
- Unsafe Rust is emphasized as a targeted “escape hatch,” not an abandonment of safety.
Language features & ergonomics
- Rust wins praise for: expressive enums/ADTs and pattern matching, Result/Option-based error handling, Send/Sync-based concurrency, clearer compiler errors, built-in linting and formatting, and consistent tooling.
- C++ is credited with richer constexpr/const-generics, placement new, allocator control, SIMD, and a deeper, more battle-tested library ecosystem.
- Attempts to define a “safe modern C++ subset” are seen by some as inherently limited and less practical than Rust’s explicitly defined safe subset.
Binary size, linking, and embedded
- Rust’s default of statically linking its standard library can yield noticeably larger binaries than C++ with shared libs, which matters on storage-constrained embedded or appliance-class systems.
- Techniques like LTO, size-optimized profiles, and
no_stdcan shrink Rust binaries, but some consider shared C/C++ libs still more space-efficient for multi-binary systems.