[duaneb]

> Many people have argued that Java, Ruby, (insert favorite language here) will one day match the speed of C, it just requires more advanced tooling, but that promise has never been fulfilled.

The primary block to this is memory management. Rust allows a superset of C/C++ memory management techniques, so there is literally no technical reason you shouldn't be able to port a c program to the equivalent rust program. Unlike java, go, etc., this doesn't break new ground in terms of optimization but rather verification of existing systems programming techniques.

To put this another way, you could write a rust -> c++ compiler and "automagically" get the speed of c++, but the same could not be said of Java.

The one area of which I'm unaware is pointer aliasing (in unsafe code, obviously). I am not entirely sure how well rust can restrict the types to optimize exclusive access to a memory region ala the c `restrict` keyword. But there's always inline assembly if that fails.

[steveklabnik]

&mut pointers ensure that they are the _only_ reachable alias to a given bit of memory.

[duaneb]

So, it's functionally equivalent to a "restrict" keyword in unsafe mode? (i.e. you can alias without the compiler being able to prove it as if you weren't aliasing.)

[steveklabnik]

My C is a bit Rusty, so I'll say that they follow http://llvm.org/docs/LangRef.html#noalias which says

    > Note that this definition of noalias is intentionally similar to the
    > definition of restrict in C99 for function arguments.

I'm not sure if they just mean 'similar' or if it's actually exact.

If you alias, you might break, as optimizations will assume otherwise.

Oh, and `&mut` pointers are safe to use, not unsafe.