Rust doesn’t have any special feature which makes it FAST and different from C and/or C++, while it is much safer than C++ because of protection mechanisms it follows which in principle, are also doable in C++, using unique_ptr and shared_ptr and to achieve the same kind of safety that Rust has, we have to do so explicitly and set down standards and force patterns that increase the development effort. With Rust, the major part which makes it safer is that coding mistakes don’t create runtime errors — it creates compilation errors.
When Mozilla talks about how much more performance they could get out of Servo’s rendering engine compared to every other browser on the planet, it’s not because Rust is doing something which is impossible with C++, but it’s because Rust makes it more securely achievable with less explicit programming effort. What this means is that performance in Rust is something that happens because you have these guarantees which make the developer more at ease with exploring higher performance methods.
Taking the effort to achieve the same kind of parallelism and memory security is not that easy, no matter how skilled developers we are, we are going to make safety-destroying mistakes here and there. Doing this in C++ means those mistakes get caught at runtime and sometimes, they’re going to only get caught in the most esoteric of repro cases, which means development is going to involve a tremendous dedication of time to just plain triage of crash bugs. In Rust, safety-destroying mistakes get caught at compile time. Obviously, we are not going to solve the problem of logic errors (which is not even possible), but effectively eliminating one class of software flaws is a pretty significant helper.
It is worth noting when the Rust project began, C++ didn’t have a lot of the safety mechanisms it has now. What eventually became C++11 with its array of smart pointers, move semantics, additional compiler keywords, etc. didn’t really exist yet. Rust was already announced about a year or so before ISO even approved the C++11 standard.
If we compare the implementations which are pretty much identical in principle between a C++ and Rust implementation, chances are they’re going to be pretty similar in performance. And in kind of naive or trial-run-at-the-problem implementations, C++ is almost always faster. Although C++ has been going into a self-destructive spiral of just throwing more kitchen sinks at the standard and for sure, there will probably be a set of new C++ idioms that grant it Rust-level safety while maintaining all its performance. Still, there’s a reason C++ is many times more highly used and will continue to be so — there’s a huge body of existing C++ code out there that’s been built up over decades. That also means that there’s plenty of C++ code that predates any modern idioms, so just because you can get there on safety, doesn’t mean you will. Because there is no real guarantee of safety without a lot of work, we as developers often hold back in C++ to the “safer” alternatives which may end up doing a lot of otherwise needless copying, not exploiting parallelism, relying on the compiler optimizations more, etc in term of ensuring the stability of the application.
Rust is still young and gaining a lot of popularity and attracting developers nowadays. There are many packages in crates and Github put out by the community, another thing is that Rust has Cargo as the standard for packaging and dependency management, which C++ probably never will.