I look at Rust with enthusiasm, but... if they are targeting "system" developers, the ones already doing that job, the last think they (we) worry about is on doing memory management errors. At some point, memory management becomes an automatic process, you just don't think too much about it.
But on the other side, perhaps the scope of a language like Rust is to bring more people from higher layers into developing engines that require performance. The Rust sales-pitch may work on people like a JS programmer but won't click yet on people like me: I just don't want to be baby-sited by a compiler.
I also noticed during my entire life that (reasonable) "fear" that C/C++ produces on developers, and the many recipes for the cure. "Script kiddies" as you call them will never target the C/C++ state-of-the-mind, let alone write system-related software: it just too difficult, and boring, and don't want to deal with truly complicated problems.
You can't solve a "lazy programmer" problem with a "language" solution. I think they're targeting the wrong audience.
Interestingly, as a Javascript developer, I see an interesting parallel here with TypeScript. You hear the argument "TypeScript is for people who don't know Javascript" relatively often - which I think is similar to referring to a compiler "baby sitting". Sure, making sure you use the correct types everywhere and don't rely on implicit type casting is an automatic process for me, but that doesn't mean I'm perfect, nor that it doesn't subconsciously still creates a cognitive load - hence why I still greatly appreciate TypeScript, even though it only helps me with things I supposedly already know very well how to do.
I think the large number of memory-safety bugs in even popular C libraries indicates that this is not the case.
The thing with Rust is that this becomes literally true. Because the borrowck pass runs automatically with every Rust compile, and tells you where it could not prove that you're managing memory correctly. And yet, the single biggest obstacle for C/C++ developers trying to move on to Rust is that they keep "fighting with the borrow checker", with only a very low understanding of what it would take to fix their code so that it can pass the automated checks. This does not inspire much confidence.
I really hope libraries like libssl and other foundational (but not considered "system") libraries are rewritten in Rust, but also believe that they should not push lower than that (kernel, peripherals, bare-metal).
I don't mind Rust either; it doesn't appeal to me, but then many languages don't. If it helps someone move forward, that's a good thing.
What isn't working very well is having Rust stuffed down my throat while being lectured by ignorant assholes who don't even know which side is up. That's going out of fashion fast.
Some of us have been around long enough to see the pattern, go back 15 years and you'll find me preaching the same gospel in the name of C++.
One thing that would help is to stop dumbing down programmers and languages, and start valuing experience and powerful tools again. The full stack developer role is a joke, and not a very funny one.
A way to save years on Java is to use the right implementations.
Do you have any evidence of this claim?
You're projecting your own experience.
I have a pretty good idea what decent C looks like, as does anyone else who spent 30 years using it.
Source, the Linux Kernel Summit 2018 and the Google sessions on kernel security.
According to Google 68% of 2018 CVE's were caused by C's lack of bounds checking.
Google is also collaborating with ARM on their memory tagging extensions to tame C.
Like everyone else you can go watch the Linux Kernel Summit 2018 talks.
Oracle also thinks otherwise, hence Solaris with SPARC ADI memory tagging turned on by default.
DoD has a report where UNIX typical exploits weren't possible in Multics thanks to PL/I instead of C.