It’s not reasonable to say that language X “is faster” than language Y. That’s a huge sweeping generalization that ignores most of the reasons performance is difficult and volatile in practice. A random code snippet written in both C and Rust might be faster in either language, and in the typical case which one “wins” has more to do dumb luck or the experience of the programmer writing them than anything to do with the languages. Which language is “winning” on a benchmarking site like that is largely about who wrote the programs being benchmarked and how much time they put into optimizing them (iirc people actually have updated these programs multiple times to make Rust and its “competitors” faster, so who’s #1 keeps changing).
In principle, “Rust is just as fast as C” in the sense that you should be able to get any program running just as fast in Rust as you could in C, because Rust has no runtime and its abstractions are zero-overhead whenever possible. There are also many cases where, in principle, Rust is faster than C because of its stricter type system (e.g. it knows
&mut cannot be aliased) and because it provides more zero-overhead abstractions (e.g. generics are often faster at runtime than passing function pointers; this is why C++'s
std::sort is famously faster than C’s
In practice, rustc is using the same LLVM backend that clang does, so Rust has always gotten most of the same non-trivial optimizations that C and C++ do. So afaik the only cases where C outperforms Rust today because it’s C (rather than because of a rustc or LLVM bug, or because the programmer knew C better) are simply missing features in Rust, like inline assembly, SIMD, alloca, etc. And all of those features are coming.