Most compilers skip optimizations when compiling in debug mode, so that it is still quick to iterate/test, then perform the optimizations which take longer to compile for release builds. Obviously it means one can only profile code when it has been compiled in release mode, which I guess has its drawbacks...

I do wish Go would do this. The fast compiler thing is fantastic, but I think we can have the best of all worlds by supporting a --release flag, and I think Go is large enough now that we can justify the extra maintenance cost of dealing with two compilation modes.

Is a "fast compiler" really all that impressive though when a lot of the speed comes from not checking things that other compilers do?

A lot of speed also comes from some decisions about the language architecture. Go packages can be compiled separately and the compilation result in binary form can be just used by code importing the packages - usually no recompilation of these packages is necessary.

The speed isn't from "not checking things that other compilers do"; it's from not performing more agressive optimizations.

Does it really matter how the compiler does it? Faster compilation speed makes programmers happier. And it's not like you can convince a C++ or Rust or Scala compiler to just trust you with the types this once and compile your program ten times faster.

I would say that yes, it does matter how the compiler is faster. Turbo Pascal, for instance, has a fast compiler (still faster than Go's last time I checked) and it is fast because it was hand-optimized in assembly to be so. That's impressive; especially so back in the days of the 286.

Golang's compiler is fast because they don't check everything they could, the language itself was intentionally dumbed down, and because it doesn't bother dealing with dependencies as tightly (or as well) as other languages. I'd say it is important to know that.

Type checking is a very small part of Rust compile cost; most of it is due to the extensive use of monomorphized code (resulting in code bloat which is not always well-controlled, to put it mildly), as well as overhead in the LLVM-dependent part of compilation. Some features in the pipeline for Rust should enable some improvements, particularly const-generics and specialization.

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.

Isn’t that the entire point of higher order programming languages?

What are "higher order programming languages"? Did you mean "higher level programming languages"? If so, no, the point is that you can program more abstractly, almost always at the expense of performance.

EDIT: Downvoters, I'm terribly curious which of these points you disagree with? Do you believe higher level languages (like Python, JS, or even Go) are faster than lower level languages (like C, C++, etc)? Or do you believe that HLLs are actually faster (or meant to be faster) than LLLs? Or maybe you are downvoting because I don't know what a "higher order language" is?

The downvotes are because you have chosen to make an irritating pedantic point about word use when the meaning was entirely clear in context.

Wasn't trying to be pedantic; whatever is "entirely clear in context" is not entirely clear to me at all. Did he use a term that I'm unfamiliar with or did he use the term I'm familiar with in a way that is incongruent with my understanding?

Informally, there is no difference between higher order programming languages and higher level programming languages.

Thanks for the explanation; I hadn't heard that term before. :)