[pcwalton]

Well, we have a production-quality optimizer (LLVM). So it'll always take some time to compile.

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.

[copx]

Will you also work on providing a better Windows package? I don't understand why you don't just bundle all the dependencies, given that they all seem to be open source and redistributable.

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.

[dbaupp]

You're spoiled :P

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

[anon3132]

Why bother working on a proper distribution of a package that isn't anywhere near ready?

It will come in its due time.

[pjmlp]

I hope Rust can eventually reach compile speeds of most module based languages.

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.

[dbaupp]

The compiler is pretty slow (although there's a big drive starting a few days ago to get certain aspects down (mostly compiling small files); because running the testsuite is so slow that work on the compiler is getting dragged down), but compiling the compiler itself is particularly bad:

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

[pjmlp]

I understand the reasons behind it.

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.

[gsnedders]

What does it use for the first-stage bootstrap, out of interest?

[dbaupp]

There are periodic (made when someone feels like it, normally every one or two weeks) snapshots, i.e. a normal bootstrap saved as a binary, of the current master branch, which are uploaded to rust-lang.org, and downloaded (once, they are cached) when building a revision that requires that snap.