Plus if you're using C at a high level you ought to be using a static analyzer anyhow, that may not impose the exact same restrictions on you as Rust, but should be imposing enough discipline on you that using Rust doesn't seem so foreign.
Yet. C++ wasn't as complex as C++ back when it was Rust's age. It wasn't even as complex as Rust. But if you pick a language for the next 20-30 years, you don't just care about where it is now, but also about where it is headed.
This is obviously easier coming from behind. You simply don't have to (and shouldn't) repeat other people's mistakes.
> It wasn't even as complex as Rust
I'm particularly dubious about this claim. Even counting from the genesis of C++ rather than standardisation, yet counting Rust as starting only in 2015, C++ after six years not only has multiple inheritance and overloading of everything, it also already has templates. That's a lot of complexity.
There's no such thing as "getting things right the first time," because what's right depends on external, mutable, factors. The best anyone can do -- and most successful languages achieve -- is being well adapted to the environment. But the environment changes. For example, Java's object model was well adapted to an environment where memory access and computation were of roughly similar speed, but hardware changed so that computation is now faster than memory access, so Java is now changing to adapt to the current environment. On the other hand, its bet that memory is cheaper than computation has so far proven relatively long-lasting. But there's no telling what needs new hardware architectures or new software requirements will bring tomorrow.
Both Java and C have adapted better, in my opinion, than C++, and it's not because of specific features, but because of their evolution ethos, which is different not only from C++'s but also from each other. My personal opinion is that C++ has tried for too long to be both high and low level, and that has shaped its particular evolution. I feel that Rust is repeating that same fundamental mistake, but, of course, others may disagree.
Take "explicit". In hindsight I suspect even many C++ proponents would agree that actually you don't want C++ conversion behaviour (when calling a function that takes a parameter of type X and you've provided a parameter of type Y, the C++ compiler will look for any way to construct an X that only needs a Y and then call that constructor rather than report that you've got the wrong type) by default. Perhaps C++ should have implicit conversion you can opt into, but it certainly should not have (as it does today) implicit conversion you must know about and opt out of to avoid blowing your feet off by mistake.
But I argue that it goes much further than such superficial mistakes. Multiple inheritance is a mistake. Personally I'm sold on the theory that all type inheritance is a mistake full stop (heritability should be a property only of interfaces), lots of people don't agree, but far fewer support the choice C++ made to embrace multiple inheritance of types. It's just so rarely even useful let alone the best option to solve a problem.
That depends what you mean by "things." Obviously, languages created in 2015 might fix mistakes made in 1985, and recognised as mistakes, in, say, 1995. But the things that a language needs to solve over its lifetime are mostly unknown when it's created. How the language handles the problems that are known when it's created is less interesting. If it doesn't do it well, it will never become popular. What's interesting is how it adapts when those problems change with time and new ones appear.
It is like handling butcher knifes without metal gloves, they think they are worthless until they repent not wearing them.
Meanwhile Zig has a lot less perceived complexity, and most of it appears to be similar enough to the "C complexity" that C programmers are already familiar to not scare them off.
(Again, I'm just giving outsider impression of someone who just read a ton of blog posts and basic tutorials + standard library stuff without really coding in either language)