Java has jars and classes and dynamic calling. You don't compile everything into one big lump, nor you have to recompile millions of lines of code for one change in a file.
If Go wanted to compete on compile speed, then dynamic loading would be a better idea than having a simplistic compiler that compiles fast into one monolithic executable.
The main reason the Go compiler is fast, is because it is simple and doesn't do many passes and optimizations.
Which is like advertising the fact that your company makes a fast car, but forgetting to mention that it can only carry a driver if he weights 10kg.
Nothing you've said contradicts my statement concerning compiling java at Google.
Go doesn't need to rely on dynamic loading because compiling a library is fast and statically linking the libraries is fast. The result is a monolithic executable true but it's still fast without dynamic loading. Go doesn't compile all the source that goes into a binary every time. Libraries get compiled into an archive and don't have to be compiled again unless they change. In that way it has the same benefit as jars for compilation speed.
If Go wanted to compete on compile speed, then dynamic loading would be a better idea than having a simplistic compiler that compiles fast into one monolithic executable.
The main reason the Go compiler is fast, is because it is simple and doesn't do many passes and optimizations.
Which is like advertising the fact that your company makes a fast car, but forgetting to mention that it can only carry a driver if he weights 10kg.