The original article is proposing that the existing C and C++ libraries be rewritten in Rust for performance reasons (while continuing to use Python to access the functionality).

I guess you meant memory-safety reasons because Rust is attempting to be as fast as C and C++, not the other way around.

Depends on the domain.

For single threaded applications, as fast is the goal. There is potential for it to be faster due to stronger restrictions around pointers.

Multithreaded code is slated to be faster mainly because rust provides safety for patterns that would be difficult to do right in C++ (see servo css handling).

That is to say, you could do the same thing in C++, but getting it right is harder to do.

Concurrency patterns that are difficult to execute in the decades old codebase of Firefox, which also happens to be a browser aka nightmare of complexity.

The same environmental conditions don't apply to other software and it's perfectly possible to write blazing fast multithreaded software in C++. In fact that's SOP.

I've heard this suggestion fairly frequently - that people use Rust as a wrapper over C++ bindings to add in safety to the C++ underneath.

Mostly regarding using BLAS etc in Rust rather than C++. It seems a little pointless as the unsafe nature is within the underlying code, so it only santises input/output.

For that use case it is more productive to actually use static analysis tooling for C++.

"people use Rust as a wrapper over C++ bindings to add in safety to the C++ underneath."

Adding a thin wrapper over an insecure library won't magically make it secure. That's why pure Rust or pure Swift versions of various algorithms and functionalities are worth so much - guaranteed memory-usage correctness.