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