[duaneb]

It's a little silly to quibble about speed when the language is still being designed. There is plenty of time to optimize the language; there's not much technical barrier to matching the speed of c/c++, especially when allowing unsafe code.

However, something I've noticed from the land of C++ is some peoples' issue with the idea that thread safety is difficult. In fact, they appear to downright bristle at the idea that they might not write perfect code and that they might lose the ability to run with fast-but-not-correct code. I don't think this is a conscious reaction, but it seems similar to what's going on in the article.

[rwj]

This is an interesting question, but I'm not convinced it is the case. 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. Many abstractions come with a cost, just look at the jump between C and C++. Perhaps Rust will match the speed of C, but I don't think it is certain.

[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.

[steveklabnik]

We're already faster than C in some benchmarks, (and slower in others, of course) and since we use LLVM on the backend, we can take advantage of all of the performance work that's put into Clang and friends as well.

[Manishearth]

I also forsee a significant speedup in complex applications caused by programmers being more free to do pointer gymnastics because they know that there won't be use after free or anything (as compared to using refcounting everywhere or a GC).

(http://manishearth.github.io/blog/2015/05/03/where-rust-real... has an example for others reading this thread)

[Manishearth]

Java/Go use a GC and have certain design principles which place an upper bound on the speed unless you want to break backwards compatibility.

Rust does not. The main issue with Rust is that we haven't gotten around to optimizing the IR properly. It's something which can be done backwards compatibly without changing the actual language at all.

The only design component I can think of which leads to bad perf is the drop flag. And that's something that should go away soon (Rust doesn't guarantee that destructors will run using this model only, so it can be changed)