But Rust also introduces complexity, while improving substantially in many areas. Of course it will do things better than what a language initially designed decades ago will do. A large amount of important systems rely on C++ and so it cannot change overnight, if at all. Rust on the other hand is free to experiment. The cost, at least in this early period, is unreliability.
When, or if, Rust becomes as performant as C++, with a comparable number of libraries and platform support, then it will be a viable alternative (and I hope that day comes). For now, the only possibility for this use case is C++.
> as performant as C++
LLVM helps a lot here. We're generally in the same order of magnitude, sometimes faster, sometimes slower. It depends, as always with performance.
> comparible number of libraries
Yeah, this is a big one. If those C++ libraries also expose a C interface, we have zero-overhead FFI, but not all of them do. Crates.io currently has 1,893 packages, with a million and a half downloads served so far. It's a start, but always a weakness of a young language.
> platform support
LLVM helps here too, though there will always be some embedded platforms and such that ship their own C or C++ compiler.
Having the compiler on your back about lifetimes/borrowing is definitely unfamiliar, but, fwiw, a programmer usually has to be keeping track of that in C/C++ anyway (if it's complex when the computer checks it, it's complex when a human checks it).
Yes, exactly. In particular, this can be seen in the syntax. There are lots of angle brackets and colons these days. I hope at some point, around 5 years from now, a version can be made that is nearly the same thing underneath, but looks more like python.
In particular, I think one of the largest sources of complexity is C++'s backwards compatibility.