Please tell that to the many millions of C/C++ programmers writing new code every day, who are only vaguely familiar with Rust if at all. If by consensus you mean "consensus amongst the vanguard of Hacker News" then yes. If you mean "consensus" as in the "consensus of the software development industry" then absolutely not.
Just call it "C20", and they will learn it in a week.
Also, Perl does not exist and is actually an urban legend from the '90s.
There is room for a new systems programming language but the current solution to the above issues is to make the code "unsafe", slower, and/or more bloated, which offsets its nominal benefits. For many C++ software architectures, memory safety is a non-issue in practice, so that isn't always a compelling feature. The benefits of Rust versus C++ are significantly overstated by its fans, and its current limitations tend to be overlooked. (I can't speak for C, it has been too long since I worked with it at scale.)
This is fairly magical when you use it but it requires a different coding style than some systems programmers are used to. Instead of writing code, you end up writing a lot of meta-code that generates and verifies what actually gets compiled. Recent versions of C++ have invested a lot in making these facilities expressive and reasonable to use in complex software. In my experience this has substantially reduced the code defect rate and simplified testing. Once you've written a system this way, it is very hard to go back.
Not having these facilities would be a huge step backward for writing practical high-assurance/high-reliability code. AFAICT, Rust is still quite primitive in this regard.
Rust does have a procedural macro system which can be used to do these things. Surely actual procedural macros are better than hacking the template system to generate custom code, which is the typical approach in C++.
(Sorry, I know this is a few days old by now...)
Due to the type system, safe Rust code has much less need for sanitizers (leaks and lock order checks are useful) or fuzzers (they'll only find infinite loops); granted, you do have a point in that sanitizers are very useful for unsafe Rust code.
There's AFL for Rust: https://github.com/rust-fuzz/afl.rs
[Edit:] With regard to theorem provers, my understanding is that you typically work in some sort of functional language and the correct C/C++ code is generated as a final step at the end (program extraction); certainly Coq and the HOL family work that way.
There's already Rust program extraction for Coq, although I wouldn't be surprised if it's not as mature as C yet: https://github.com/pirapira/coq2rust
In other areas, Rust already has an advantage; compare Cargo with the Babylonian chaos of C++ build sytems, where the question isn't even which one you want to use, but how many different ones are imposed on you by external constraints and how to integrate them without going crazy.
Provers are also a fair complaint, though it’s going to be comparatively super rare that that is an issue in practice :p
While C's copy-paste compatibility is C++ security story Achilles heel, there is still quite a lot that can be used for writing safer code.
https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...
Yet, this is good to see C++ trying to catch-up. (And if it's catching up, it means Rust is ahead in terms of static analysis ;)
The difference is that C++ makes it convenient to write unsafe code, but that it also makes it possible to write safe systems code at a much higher level of abstraction than any other language I’ve heard of (templates are Turing complete, and modern tooling makes them reasonable to work with).
So, the question is, what does Rust make C++ developers give up that can’t be achieved via C++ style guidelines?
Also, 10 years from now, when the state of the art of systems programming advances, we’ll be able to backport the ideas C++ (just like we do today).
Does Rust have a track record of supporting that?
I'm really skeptical of backporting Rust's wins to C++. The concept of mutability cuts across the language and I don't see how you do it without bifrucating an already complicated language.
How hard would it really be for someone to write a static analyzer for C++ that ensures there is only one non-const reference/pointer to an object active at any given time?
Throw in an object lifetime tracker for allocs and you'd have pretty safe C++ without having to rewrite a billion line of code.
At work we use a pretty big C++ library maintained by absolutely brilliant people, and there still are memory issues and the occasional segfault. It gets tiresome. I'm not convinced anyone can write really safe C++, whereas outside of `unsafe` it's quite easy to write safe rust.
[citation needed]?
I could definitely believe there are such things, but all the examples I've encountered are things like doubly-linked lists where the complainer flatly ignores the existence of the 'unsafe' keyword.
But every sane safety advocate also acknowledges that we aren't going to throw away the millions of lines written in C and C++ tomorrow, and there needs to be a way to keep UNIX derived platforms, while improving their security.