If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.
At the very least, the fact that IDE integration can tell you all kinds of stuff about what you're doing/doing wrong and why accelerates things greatly when you're starting out.
I don’t see a way around it, programming without garbage collection is hard, Rust makes it very clear very quickly, which is also the point, but this is at odds with making the learning curve accessible.
Yes, this is the biggest issue with Rust that I've seen; most language will let you do something wrong and then as you learn you get better. Rust will refuse to compile if you're not doing things correctly (and normally I would put 'correctly' in quotes but correctness in Rust is well defined).
The first time I tried to experiment with learning Rust was a disaster. I just wanted to decode some JSON and filter it, but -- oops! -- I don't own that variable. Okay, well I can pass it somewhere else mutably, right? But then that function does the work and returns something that... what's a lifetime? What's a 'a mean? How do I... screw it, I'll go back to Python.
Eventually, after the tooling and the tutorials got better I came back to it and really enjoyed what I've seen so far and even rewrote one of my own personal tools in Rust[1] to experiment with. It's nothing impressive, but it was fun to do.
The logic in my comment wasn't that you need to have written considerably amounts of code to be expecting this, just that to not be expecting this would make me think you hadn't. If that makes sense.
On your second point, I think IDE integration for C++ is similar as it is for Rust. Just Rust errors and tooling are a million times better regardless of IDE.
Now, if they actually "see" it is another matter.
Let’s end the C era.
Swift Concurrency is a tire fire that not even their async-algorithms team can use completely correctly, and useful feature like typed throws are left half finished. The enormous effort the constant further bastardization of Swift takes, is at least in part the reason for the sorry state dev tooling is in. Not even a 4T dollar company can make a reliable SwiftUI preview work, in their own IDE. Variadic generics (a seemingly pure compiler feature) crash at runtime if you look at them the wrong way. Actors, the big light tower of their structured concurrency, are unusable because calls to them are unordered. They enforce strict concurrency checking now, but the compiler is too dumb to infer common valid send patterns; and their solution to make this abomination work in real codebases? Intro a default that lets _everything_ in a module run on the main thread per default!
</rant>
