C++'s complexity is also a product of design choices like using templates to do both generics and metaprogramming, which in hindsight probably made things much harder than they needed to be. Rust has the benefit of being able to avoid decades of C++'s missteps.
However, I do know that a lot of objections to it from the people I follow are around the borrow checker and both the friction and high[0] compile times it causes.
[0] to put that in context, Jon is frequently annoyed by the sub-second linking time incurred by LLVM because it is more than an order of magnitude longer than his largest program (~60k line game, IIRC) takes to compile.
What makes it worse is that complication doesn't even exist for "good" technological reasons; it only exists for inertial, industrial reasons like compatibility with C and 1980s naivete -- both because of and in spite of it, since, like the other person said, even more complexity was bolted on to try to force new lessons without breaking backwards compatibility.
I used to love C++, since I thought its complexity was somehow, fundamentally necessary for a lang to be a "fancier C". Once I learned Rust and found out that was not true, I now hate C++ with a passion and can't wait until it completely displaces C++, which it should do ASAP[0]. :D
THAT SAID, some people (who are much better programmers than I am), say that C++ is the most expressively versatile language around, which is at least a "good" technological reason for its enduring existence. That's one I can't relate to, though, since the people who are saying that tend to be talking about very advanced, byzantine aspects of C++ that I never got to.
This has happened pretty regularly for decades at this point, people hate on c++ and think they have the silver bullet approach to do things better. They spend a few years on it, and it fails to get much traction.
There is a network effect around c++, sure. But industry standards are there for reasons, and usually most of them have a core at least that is sensible. People keep coming back to c++ mostly because it works, and it turns out often if you start with a safer and cleaner language you get 80% of the way there much faster, but a lot of the 20% that's left over is performance related and you just can't get there no matter how hard you try.
So from a business point of view, the pain level of c++ (and associated costs) is somewhat known, but most other approaches trade that off against project risks people just aren't willing to take.
It's not inherently crazy, even in 2021 to start a new high performance project in c++. Obviously the exact requirements matter, but there is a subset of what it can do that we don't really have a obviously good replacement for. What would be crazy is starting a new project in it that doesn't really need any of thee things it's good at.
I disagree. I follow a lot of game developers and you'd be hard pressed to say they don't do high-performance corss-platform native application development. They almost universally think C++ (and by extension Rust) are too complicated. They generally use C++ anyway because that's the industry standard, but they think there is definitely a conceptually less-complicated way to do things.
See: Jonathan Blow and Casey Muratori, for instance. The former is so sick of C++ he's making his own programming language, and the latter routinely complains about C++'s complexity and eschews all but the simplest features of it.