You are mistaken about #2, optimization pass is not very relevant in total build time, even for compilers that spend a relatively long time in the optimization pass. Go build times are fast because 1) the grammar is not ambiguous to yacc yielding an O(n) parser that doesn't require maintaining a symbol table, 2) Dependency resolution is handled in an unique way, objects pull their dependencies so if A depends on B, C depends on A, and D depends on C and B, D doesn't need to look for B, since C contains A, B, and C. This doesn't seem like much, but it is, build times scale linearly with the number of objects instead of O(n^2).

The gc suite doesn't produce code as tight as gcc, but almost no code in the world is CPU bound, everything is I/O bound.

Could you link to a resource that describes Go's dependency resolution scheme? Specifically, I'm curious if this means that all libraries are dynamically linked, and if so, if this inhibits Go's ability to inline function calls between libraries.

Go libraries are statically linked and inlining works across libraries.

Dynamically linked libraries are actually a little problem in Go. Library is opened via dlopen()/LoadLibrary() and symbols needed are looked up by the Go code, not by system dynamic linker.

That's not true at all. In the few cases where dynamic linking is involved, it works just as you'd expect it to be.

Go does not use native dynamic linker.

Please check package syscall, specifically src/pkg/syscall/dll_windows.go. You will see for yourself, how it is implemented.

I find gcc usually spends about 80% of the total compile time in optimization with -00 as a baseline (which despite being 'no optimization' actually does some optimizations). This is just C code.

Optimization takes a massive proportion of compile time these days. This is something the Google Go designers didn't understand because they had been programming for decades using a mostly unoptimizing compiler (for plan 9).

You will find that even though GCC spends 80% in the optimizing stage (I won't bother to refute your claim), impact of this is negligible in the grand scheme of things. The build is slow is because it scales O(n^2) with the number of files, and because there are many more steps involved in building a product, not because the compiler is slow (although GCC is).

Go is designed to handle dependencies between objects in such a way so that it scales O(n).

The Solaris/OpenSolaris/illumos build builds with two compilers at the same time. The Sun/Oracle proprietary compiler that generates better code, and GCC. GCC generated binaries are not usually used, instead GCC is used a shadow compiler to catch potentially not portable statements.

You will find that if you disable GCC and build with only one compiler, build time decreases by 2%, not 50% as you might have expected.

Well it's true that the Go compiler isn't comparable to GCC in terms of optimization but it's still quite new and is likely to improve quite a bit. As for Go supporting other compiler backends that's already happening with GccGo which is a Go frontend for GCC and yes it does generate much faster code than the official compiler (although it still lacks some key features last time I checked).

I don't think we'll see GCC (or LLVM) as the official backend though, as they've stated that the reason they decided to do the whole compiler from scratch was that both gcc and llvm backends were considered too large and slow.

> although [gccgo] lacks some key features last time I checked

Not anymore. Gccgo is "Go 1 complete" and will be supported as part of Go 1. You can even use the "go" tool with gccgo.

Thanks for the info, that's very nice. I can see this opening up a workflow where you develop against the standard compiler and then use GccGo for better performing final builds.