[steveklabnik]

That chart is extremely old. We are sometimes faster than C in the benchmark games, with the exception of SIMD stuff due to it not being stable yet. (and, it can fluctuate, depending on the specific compiler version, of course.)

For example, here's a screenshot I took a few months ago: http://imgur.com/a/Of6XF

or today: http://imgur.com/a/U4Xsi

Here's the link for the actual programs: http://benchmarksgame.alioth.debian.org/u64q/rust.html

Today, we're faster in C than one program, very close in most, and behind where SIMD matters.

  > But C has decades of lead time.

Remember, Rust uses LLVM as a backend, which it shares with Clang. So all that work that's gone into codegen for making C programs fast also applies to Rust, and all of the work Apple and whomever else is working to improve it further, Rust gets for free.

[SolarNet]

I mean true, I'm playing devil's advocate here. I respect the Rust community (heck of all the nu-c languages I respect it the most, I even did a poster on 0.1 of it for my programming languages class), I will be quite impressed if they can pull off (and they are the most likely to be capable of it in my opinion) what so far has been an insurmountable task: beat an old guard language in general purpose performance (Fortran, C, etc.); languages that have every advantage but design foresight. If they do it, it will be a great historical case study on how to build a new programming language.

As an aside: As someone who has used LLVM to build a compiler, it doesn't quite work that way, yes rust has access to those gains, but it may not be able to effectively use them (due to differing assumptions and strategies).

[steveklabnik]

Totally hear what you're saying on all counts :)