> Well you are saying that even in C you can use the restrict keyword to tell the compiler that 2 memory locations can overlap. Of course is in the hand of the programmer to tell the compiler to do so.

It says that they can't overlap, but yes, you can get the compiler to optimize based on this if you provide the aliasing information and remember to keep it accurate. You probably won't do that, though, for anything except the most performance-critical of inner loops. A compiler that can infer more about aliasing can provide more optimization, safely, in the >99% of code that doesn't have explicit aliasing annotations, and that's probably worth some decent speedups in practice.

There are two main things you might be talking about when you call a programming language fast:

1. Given some really performance-critical code and enough time to hand-optimize it, how close can you get the compiler's output to the optimal machine code?

2. If you write code normally, not making any effort to micro-optimize, how fast will it usually be?

Both of these matter. #1 matters when you've got some bottlenecks that you really care about, and #2 matters when you've got a flatter profile -- and both situations are common.

Another illustrative example of the #2 type of performance with Rust is the default collections compared to the ones in C++. Rust's default HashMap is faster than C++'s std::unordered_map because of some ill-advised API constraints in the C++ STL. You can get similar performance by using a custom C++ hash table implementation, and in fact Rust's HashMap is a port of a C++ hash table that Google wrote for that purpose, but most people probably won't bother.

So, a semantic question: if you can get the same speed in one language as you can in another, but in practice usually don't, is one language faster than the other?

People think C is an high level Assembler, that was only true on PDP-11, 8 and 16 bit CPUs.

Also in C you cannot retrofit restrict in existing programs, specially they depend on existing binary libraries.

> Thus the contrary cannot be true for Rust: if I give you a heavily optimized C program not always you can produce an equivalent version in Rust.

Do you have some evidence here? Or something more specific?

(The rest of your comment is opinions, which you can of course have, but does not match my personal experience, FWIW.)

There's a translator for C99 to (unsafe) Rust: https://github.com/immunant/c2rust

So probably you can give me any C program and I'll be able to give you an equivalent Rust program. It'll probably perform about the same, too.

> That is the difference between C and Rust to me: for each fast Rust program you are guaranteed that you can write an equivalent performant program in C (or assembly). Worst case scenario you use inline assembly in C and you get that.

Rust also allows inlining assembly.

> Thus the contrary cannot be true for Rust: if I give you a heavily optimized C program not always you can produce an equivalent version in Rust.

This is incorrect for the reason above. Worst case scenario you just inline assembly in Rust to reproduce exactly the same performance of any arbitrarily optimized C program.

I think you'd be hard pressed to find more than a handful of usual C programmers, even in embedded, who know what the __restrict keyword does, let alone are rigorous in its application.

> For the same reason Rust is the ideal language to write viruses, since it's difficult to reverse engineer.

Eh, not really.