How does Rust compare against C++ with Coverity? Because that's the real baseline Rust should compare to.
Basically the net effects are a mix of: 1. Push more computation to compile time rather than runtime 2. Verify a lot more state at compile time, preventing dangerous or nonsensical state from occurring altogether 3. Because of 2,you get hard guarantees about the runtime state e.g there is no chance of encountering undefined behavior in safe Rust 4. Building, testing, and deploying are all quite straightforward in almost every Rust project. If you can get away with simple statistics, benchmarking is very simple too. The ones that don't typically have native non-Rust dependencies
As an end user running a server, i very much care about whether my web server has vulnerabilities. And the promise about safety is not vague, it has clearly defined semantics.
To comment on your last point, it's seeing some light already, ripgrep is already beating grep in performance and is purely written in rust. And i agree that this is how rust will beat C++(if ever), by writing "better" tools than those already exist.
See, people don't care about safety, they tend to want the language to get out of the way. C++ does that because it does not get in the way of a C standard library. Or other system specific stuff.
Rust gets in the way enough that the benefit seems not worth it, and it brings few benefit in the server space over, say, Java if performance is not the paramount concern.
It's definitely an area where the closed source tools are ahead of the OSS alternatives, but there are open source (and free closed source) alternatives to Coverity. PVS Studio, for example, has a free download: https://www.viva64.com/en/pvs-studio/
> As an end user running a server, i very much care about whether my web server has vulnerabilities. And the promise about safety is not vague, it has clearly defined semantics.
You say that, yet you're still running a ton of software written in C and C++.
Nice assumption. Much of the software I use is actually implemented in Rust. And soon, I'll be using an operating system that's 100% written in Rust, with a 100% Rust Servo-powered web browser. It's only a matter of time.
In addition, I've also implemented my servers (web server included) in Rust, and they have zero dependencies upon C/C++ software, so your entire point is rendered invalid.
For many, Cargo is the main selling point of Rust. Then there's the ADTs, move semantics and move-semantic-powered features(borrow checker & compile-time-checked state machines), compile-time static code analysis, FP capabilities, traits and trait-based generics, pattern matching, and the miscellaneous tools and communities surrounding Cargo / Rust. None of which you can obtain with C++. Not to mention how much better the syntax of Rust is compared to C++ -- being able to succinctly express complex patterns in simple, human-readable terms with no room for context-based ambiguity.
As a C++ developer, I think Rust's main selling point (memory safety) isn't as big of a problem as it's made out to be. For every unsafe memory access that results in a crash or exploit, there are millions and millions of memory accesses that work just fine and never cause a problem. Tools like Coverity and Valgrind can catch a ton of errors, and its not clear Rust offers any significant advantages over C++ with Coverity.
Parallelism is nice, too, but C++ already has a ton of options there: OpenMP, MPI, TBB, OpenCL, standard library threads, boost/standard library async tools, etc.
On the other hand, as an end user, "written in Rust" or "written in <any language>" isn't something I care about. I don't even remember the last time I had a piece of software crash due to a seg fault, so a vague promise of being "safer" isn't good enough to accept an otherwise inferior product.
I guess to summarize, C and C++ developers are going to keep writing C and C++ and if Rust is going to take over the world, the people advocating for it will have to write better software in it and beat out software written in the other languages.