Rust is clearly aiming to match C++ in complexity.
I don't know whether this is “Death by committee” in a new wrapper, only this time it's the "community," driven by Github emojis, as opposed to legacy processes you would find in C++ committees. Upon closer inspection, there's so much more in common between the two than it would seem! The most glaring difference is cadence. C++ is evolving slowly, and the newer stuff is not rushed into codebases. Rust projects are commonly staying on the very latest stable releases, & in some instances, nightly builds—to compile. I primarily interact with Rust codebases in the context of Postgres extensions, and I can tell you one thing: constantly having to update Rust toolchain to keep my databases up to date is a _massive_ chore.
Curiously, it would appear that the niche Rust is occupying nowadays has very little overlap with C++ applications, and so much more overlap with C. We're beginning to see more and more of Rust creeping into C projects. Meanwhile, the not-so-recent addition of smart pointers, coroutines, and the more recent improvements on these designs have allowed C++ codebases to evolve at predictable, clearly-defined pace. There's definitely a battle for C++ mindshare going on, and it's really not been good outcomes for Rust people. I'd like to remind you that most large-scale orgs where performance and stability truly matters, are still overwhelmingly C++. The HPC world basically runs on C++. The AI landscape, that is, you could make an argument, merely the extension of HPC—is similarly dominated by C++. CUDA is fundamentally an extension of C++. The larger CUDA toolkit and programming guides primarily use C++ syntax and features. Legacy? Sure. This is also the case for the majority of emergent projects in the field, including ROCm, JAX, Tenstorrent stack, and consequently the vast majority of higher-order frameworks such as llama.cpp, torch, vLLM, TensorRT—all rely on C++ compilers. Rust is virtually non-existent here, which was surprising to me originally, as I would expect Rust people to be interested in homogeneous computing, but it's started making sense when I looked at Rust-CUDA compatibility matrix.[1] Turns out, it doesn't really support anything useful for performance, and the things that it does support—all have asterisks next to them.
The Rust community is obsessed with a handful hyper-important projects, such as Linux kernel, Android, Postgres (via pgrx[2], where it has been incredibly useful!) etc. IMHO, this is very telling, & a part of the larger strategy. Ignore, or re-write small projects with no intent to maintain them later, abandon the more ambitious Rust-native projects, and focus on some of the most high-profile C projects with sufficiently-large surface area, where memory safety has traditionally been a problem. You could make an argument that Linus Torvalds is, frankly, exploiting Rust evangelists, and avoiding any bad publicity that denying them completely would entail, instead opting to direct their energies towards the most boring stuff possible: the driver subsystems. This is changing, of course, most notably with bcachefs (Kent is very fond of Rust!) and we have recently seen how that played out.
The Rust Foundation needs to think about optics; it doesn't look good at all.
On the other hand, I've grown to appreciate, and indeed, tempted to write some simple programs for Xous[3], of Precursor fame, which is a really nice bit of kit, and cleverly designed, too. (See pddb[4] work by bunnie circa 2022, it's really quite exciting!) Honestly, this is Rust at its best: a Rust project written from scratch, for good, technical, no-bullshit, no-compromise reasons where it matters the most, and actively maintained, too. Although with the return of memory tagging technology (pioneered by IBM in the 90's) in Arm v9, formally-validated CHERI designs, I'm not yet convinced Rust itself provides enough oomph, hype notwithstanding, to justify much wider adoption. It's been 10 years since Rust 1.0 and the wider industry adoption is otherwise quite underwhelming. They're no longer the new kid on the block; in view of "speedrunning" feature cadence, most notably culminating in the whole async debacle—it's not looking good at all. The Rust Foundation is routinely exploited by big corps in the stark-naked pursuit to harvest young talent, but other than a few small, hyper-useful applications, like ripgrep, alacritty, a few Rust-only shops (Oxide?) and activism largely directed towards legacy C projects, recognised by StackOverflow as "the most loved language" who knows how many years in a row, industry-wide adoption really has been lackluster _at best_.
Contrary to popular belief, C++ is getting easier on the eyes as years go by, at the same time Rust is only getting harder to read. I really liked the direction they originally took back in 2014, but they're now far beyond the point of no return; the proc-macros and arcane cargo mechanics, are only making the matter worse. If I were a betting man, I would predict that C++ will eventually incorporate most of what makes Rust great: borrow-checker, and many alternative approaches are floating, & gaining traction. The static analysis and perf-class tools have come a long way. Fuzzing, too. Modern C++ is already very different from C++ of 10 years ago, and many orgs choose to only use a specific subset of it. The same is happening in async Rust, but the larger language and tooling design doesn't lend to "siloing" as well. I personally stopped writing C++ professionally for 5 years after I stopped contributing to KDE projects, and when I came back to learn about lambdas, smart pointers, move semantics and all, it was quite straightforward. The amount of tooling that C++ had accumulated during this time is quite staggering, and their traction speaks for itself.
In 2025, more C++ is being written than at any time in the past, and young people are learning it, too. To them, from POV of "Modern C++" a lot of arguments Rust people are making—seemingly falls on deaf ears. If C++ were the dominant ideology, and Rust the subverting one, it's clear that the former is set on incorporating the latter in its discourse. What usually happens in such scenarios is longterm it boils down to taste. IMHO, in matters of taste, C++ is more flexible (to agreed-upon subsets) than Rust could ever allow today, and I struggle to see how this asymmetry could be reconciled; there is seemingly no appetite for it in Rust circles outside of async runtimes.
EDIT: Don't forget about LLM technology! There's orders of magnitude of C and C++ code of various styles around. The primary selling-point of Rust is that it enables memory and thread-safety, right? If the sufficiently-advanced AI agent runtime is able to troubleshoot and address them in time, it would become much less of an issue. Many security companies are already using LLM tooling to catch various vulnerabilities, and sometimes even bother the maintainers with it, demanding CVE's assigned and all. There was a thread on HN recently covering this topic. The agent runtimes have dabbled in super-optimisation and even writing highly-sophisticated fused kernels; guess what language it's all been done with?
[1]: https://github.com/Rust-GPU/Rust-CUDA/blob/main/guide/src/fe...
[2]: https://github.com/pgcentralfoundation/pgrx
[3]: https://github.com/betrusted-io/xous-core
[4]: https://www.bunniestudios.com/blog/2022/the-plausibly-deniab...