You are absolutely correct. I should say that the THEORETICAL performance of Rust may be competitive with C++, maybe even faster in some cases, but that work remains to be done to get it there. My above statement assumes that this day will come, or that the performance at least reaches a point that will allow a reasonable engineer to choose Rust over C or C++ for something that performance is a crucial consideration for.

There are actually cases where Rust is faster than C already, one of the reasons being the compiler emitting better code thanks to mutable aliasing being forbidden.

http://benchmarksgame.alioth.debian.org/u64q/rust.html

It's not why C is faster, it's more about being able to use hand crafted SSE2 instructions and existing libraries with such optimizations. Nothing competes with C when performance really matters.

You can use "hand-crafted" SSE2 instructions and libraries with the same in Rust. Servo heavily relies on Skia, for example…

There is also a case for making highly optimized C performance easier to attain, without needing to resort to unsafe code. You can do this by providing more invariants to the compiler via a better type system, which gives it more room to optimize. It may never get to the performance of hand-optimized stuff, but for that there is unsafe code blocks.

Technically Fortran does compete. For computational applications it is faster than C and hence why it's so popular in supercomputing.

Feel free to use the asm! macro in rust when you need to. FFI support is also quite good.

I think the point is that machines are fast enough that being as fast as C++ doesn't matter anymore.

True for many things. But there are still plenty of things that we still want to do faster or cheaper or that we want to feed more data to, and we also still find plenty of new things to do as computers get more powerful.