> Rewriting it is way, way too expensive, risky, and, honestly, doesn't seem to make sense except in the heads of the most frantic Rust fans.
I've met hundreds of rust developers at this point and at no point in conversation has anyone ever expressed that we should be working to rewrite every C++ project in Rust.
> for example Vala, Cyclone, Limbo, BitC. How many of you have even heard of these languages?
I'm aware of Cyclone and Vala, not the other two. Vala isn't even a little memory safe, so not sure why it's mentioned. Cyclone was a research project from my understanding, and that's it.
> By the way, most of the critics have never seen C++ code in production.
Not true.
> Rust is safe indeed but, unfortunately, far from fast. By the moment of writing this article, it is comparable to Java, Go, and Haskell regarding performance:
Old benchmarks, no discussion of why those benchmarks are the way they are. Benchmarks without analysis are just meaningless charts. Old benchmarks are even worse.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Here's the up to date benchmarks.
> or if it is automatically doomed to be twice slower than C/C++ because of the constant checks for array overruns, safe wraps of bindings to C-libraries, and other stuff like that.
There are a lot of really interesting reasons why Rust is slower in some benchmarks, like lack of constexpr or int generics, which at least one C++ benchmark uses heavily.
> But these are actually two dialects of one language, which doesn't look much different from the "Java + C" or "Go + C" combos.
Practically, there is a world of difference, given the lack of 0-cost FFI in eithe rof the mentioned languages.
The rest of the article is just disconnected conjecture, I stopped reading. If anyone thinks there's value to finish it though, let me know, I'll circle back.
edit: It occurs to me that I'm not reading "The next in a series" but actually an extremely dated article that wasn't accurate in 2015 and isn't accurate now.