I have played with rust, but not written any large amounts of code. This makes me a bit sad though, I have 7000 lines of go which takes less than a second. I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out.
Compare gcc/clang/rustc build times from source with building go 1.5 from source which bootstraps itself. It comes down to something like 20 minutes vs 20 seconds.
There's certainly a lot of room for improvement in Rust's build times, but LLVM was completely indispensable for the language to get off the ground, and I don't regret using it for a minute.
LLVM is a great innovation when it comes to making new languages from scratch, High performance will hopefully be one of rusts strong points, so its good to have so many companies working on llvm performance for free.
Niko Matsakis is actively working on improving typechecking time--there should be plenty of tricks we can try once we have enough data as to the lowest-hanging fruit. Felix Klock and others are working on reducing the amount of LLVM IR we generate to speed up codegen. There have also been designs for incremental and parallel compilation that will be long-term but have potential for big improvements down the road.
I think with careful work we can get down to a good edit/compile/run experience. Compilation speed probably won't ever be as good as a direct-to-assembly compiler for language with an extremely simple type system with no real IR for optimization would be, but I don't believe there's a magic bullet that will beat LLVM's compiler performance while providing excellent optimization, and for Rust's goals we need the runtime performance.
But I guess it is a block for those used to programming languages with traditional interpreter implementations.
My biggest complain when trying out Rust was the C++ build times of the bootstrapping process. As for using pre-compiled Rust, I think the compile times are pretty acceptable for 1.0.
This isn't just an "LLVM is slow" problem, though. It's also a "rustc generates extremely verbose LLVM IR" problem. Optimizing the IR before it gets to LLVM is part of the plan for solving it.
(Also note that compiling a C++ file with 2000 lines can take a very long time too)
E.g. I have a very innocent 2000-line MainWindow.cpp that weighs 244419 lines when measured with gcc -E -o - | wc -l
I feel like there are some projects out there that trigger things with bad runtime complexities in Rust. I had to stop using the piston image library because compiling it takes 15 seconds every time, which I'm not in for.
Compiling racer currently needs 2GB of RAM for no good reason.
So I'm pretty sure there is ample room for optimizations.
Here he is talking about it:
You could have a more C-like language that isn't so dependent on expensive optimization passes like multi-level inlining and SROA, granted, but I think most any high-level language—i.e. one that isn't a bare-metal language like C and Pascal—is going to have lots of opportunity for expensive optimizations.
For any developer that never used Turbo Pascal, Modula-2, Oberon compilers, just to cite a few examples among many possible ones.
Those that did, can not comprehend why companies invested in languages like C and C++, which created this notion all compilers should be slow.
Be more specific.
1. Plan9 C does not allow headers to include more headers, this speeds up compilation, as there is far less useless preprocessor churn.
2. Plan9 C/Go does not do heavy optimisation, but does a decent job.
3. The system has less code overall, something like 1 million lines of code for something like gcc seems like bloat to me, They don't remove useless features and dated features as fast as they pile it on.
The whole Go compiler builds from source for me before the gcc configure script has completed.
That's not good enough for Rust.
> 3. The system has less code overall, something like 1 million lines of code for something like gcc seems like bloat to me, They don't remove useless features and dated features as fast as they pile it on.
Those GCC optimizations matter. You simply cannot get away with competitive performance with an AST-to-assembly plus peephole optimizations on the assembly anymore. SROA, SCCP, loop invariant code motion, algebraic identities, vectorization, aggressive alias analysis, etc. are all very important.
I do want more specialized optimization tools however. Things like automatic super optimizers  which can be targeted by programmers with special directives.
2) heavy optimisation is not "bloat".
3) "seems like bloat" is a too vague argument. Fine enough point about them supposedly not removing useless features.