You can run Rust completely without a runtime. Part of the reason for that is that there are much bigger performance hawks than you or me monitoring Rust who have significant input on its implementation. That is one of the reasons that Rust moved GC into a library, for example. The last thing I am worried about with Rust is its performance.
That doesn't say much about performance. Languages that do need a runtime, like Java, aren't slower than C++ because of the virtual machine per se (which otherwise does a good job at doing awesome optimizations that are only possible with runtime profiling), but rather the reliance on a garbage collector and the lack of options for fine tuning the memory layout / access patterns and unfortunately the runtime is not smart enough yet to do that for you. Every language that depends on a GC, but that wants to be close to C/C++ in performance, starts with this handicap, even though for most purposes an efficient garbage collector will behave much better than inefficient usage of malloc or a half-assed object pool.
Of course I wouldn't worry about Rust's performance either.
Awesome. Rust's performance is something that impresses me, so I'm certainly not suggesting that it's slow. The point I was making is it's a valid question to ask and a valid thing to measure. Having fought with slow language features (e.g., blocks in Ruby), slow stdlib (e.g., older versions of Scala's collections), and slow techniques adopted by library authors (e.g., ask for forgiveness with exceptions instead of permission) there's just a lot that impacts many if not all apps and if it's outside your own application code, it can be very hard to fix. One of the things I really like about go releases is they indicate exactly what's changed on the performance front, so I have a good idea of what to expect. And since they measure it, they can improve it.
Sure. I think that until they hit 1.0, the Rust devs want to concentrate on getting the language semantics right. The most important thing is that Rust CAN be made fast even if it is not fast today (but I'm not suggesting that it's not fast but it probably has room for improvement). You can't make e.g. Ruby fast while maintaining backwards compatibility.
