Eventually once all of our LLVM patches are upstream and the versions including the patches make it into common repositories you may be able to use your system LLVM to compile the Rust compiler, at which point the compile times will drop dramatically.
We continue to work on compile speed of Rust code all the time.
Call me spoiled but I expect a one-click installer in this day and age. I still haven't tried to actually use Rust because of that and I am sure I am not the only one.
It will come in its due time.
But, windows is (unfortunately) a bit of a second class platform at the moment (although there have been some very big strides in the last week or so). So part of the reason for poor windows packaging is Rust isn't ready on windows yet (even more so that its normal pre-alpha-ness on Linux and Mac).
Every time I update my netbook with a new Rust release it takes a few hours, it almost feels like I am compiling KDE or something.
- it has to build LLVM: Rust currently has to use a custom version; the goal is for this to be unnecessary so that the system LLVM is ok.
- it has to build itself and the standard libraries 3 times: rustc is written in Rust; so it has to bootstrap.
- it eats a lot of memory, so bootstrapping on low memory systems is bad. Much of this is historical; the bootstrapped code means that large portions of the compiler are written when the language was less developed, and so is very non-idiomatic. It's progessively being modernised
The first and last can be fixed; the second can't, at least until there are binary releases.
Given my experience with compiler development, back when I was in the university, my expectations is that the second point would be pretty fast anyway, if the first and last issues are solved.
I have good experience with languages that use modules, some of them had bootstraped compilers like the Oberon family.
That is why I said I am hoping for these issues to be solved, as I think building LLVM is the main culprit.