Hacker News new | past | comments | ask | show | jobs | submit login

Go is specifically designed for fast compilation. You can't just skip some checks and get similar results.

Nobody is expecting Rust compile times to ever match those of a language whose premier guiding principle is fast compile times, but the question is whether or not Rust compile times can become fast enough to keep Rust programmers satisfied. I'd say that programmer attention span is generally sufficient to tolerate iteration times of five seconds or less for interactive editing. Who knows if Rust will manage to get there, but the Rust developers I've spoken to seem to earnestly believe that an order of magnitude improvement is possible (over the course of several years of development, however).

I think what people are trying to get at in this thread is that they'd be happy if their Go compiles took 0.5 seconds instead of 0.1 seconds, if it also meant that it lessened the need to manually employ the techniques in the OP. Of course, keeping such tradeoffs within reason is a difficult prospect.

> the Rust developers I've spoken to seem to earnestly believe that an order of magnitude improvement is possible

I'd like to believe this is the case, but has that ever actually happened - as in a programming language seeing that much speedup in its compiler? There're quite a few cases of languages that are generally taken to have long compile times (C++, Haskell, Scala, etc) but I don't know of a case where any has been able to improve by as much as an order of magnitude.

Often speedups of that magnitude involve "cheating" by somehow rethinking the problem space. An example of this applied to compilers is the venerable ccache, which absolutely does provide a 10x improvement or more compared to naive use of the compiler (in this case the "cheating" is caching build artifacts so that most things don't need to be re-built at all; this is often devastatingly effective). I also suspect that the reason we don't see compiler developers regularly advertising order-of-magnitude improvements is that these improvements often span a decade or more of work. Clang 2019 may not be 10x faster than Clang 2018, but it very well might be compared to Clang 2004.

As for Rust specifically, a benchmark I saw a while back estimated that modern rustc compilation is about 3x faster than it was as of the 1.0 release in 2015. Other "cheating" approaches to reducing build times for Rust are incremental recompilation (which is kind of like built-in ccache), parallel codegen units (the original rustc, ironically, was single-threaded), a compilation mode that stops after typechecking (thereby avoiding codegen and LLVM entirely; this is invoked via `cargo check` and suffices for much of one's interactive development), and an alternative debug-build backend (Cranelift, still very WIP) which is optimized for extreme compilation speed (like a browser JS engine) rather than compilation quality (LLVM being largely designed for the inverse).

Indeed, the first step to making a fast compiler is "design your language from the start such that it can be compiled quickly" (which can be seen in the design of Go). I can think of a few things in Rust that might have been designed slightly differently (in the name of compilation speed) if the authors had the compiler-building wisdom they do today. But there are still plenty of opportunities to improve here.

C++ precompiled headers easily can give you your factor of ten.

Also, taking ‘its compiler’ literally: Turbo Pascal was over ten times as fast as earlier pascal compilers for the same hardware, which were multi-pass.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact