One thing I especially appreciate about Go that's a huge win over other statically compiled languages is how phenomenally fast the compiler is. E.g., I just re-built the current RC release on my 2.67 GHz i5, and the whole build, including the C bootstrap environment and 300k+ LOC in the standard library, took under 30 seconds.
Recompiling my projects of a couple of thousand lines is instantaneous. It really makes you re-think the classic edit-compile-edit cycle since the compile time is negligible.
I wonder why people are so impressed by the compile times. Why it is fast, is obvious:
1. Do not use #include (especially in combination with C++ template instantiation)
2. Do not use a heavily optimizing compiler backend
The first point is fixed in every other modern language as well, so it is only an advantage over C/C++. Go will become somewhat slower, because people want free lunch, so at some point i expect LLVM or GCC will be used as the official backend. Does anybody use TinyCC for his C programs?
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.
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.
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.
Any language with modules is equally fast, only languages the use the C #includes mechanism are slow, because each #include needs to be imported and processed each time it is seen.
Turbo Pascal, Modula and Ada compilers were already running circles around C compilers back in the day.
It's absurd to claim it's marketing since in this exact thread people state they care about this things and appreciate the feature, a feature that can be quantitatively tested.
Btw, The Plan 9 C compilers, which are also included with the Go distribution, also compile C as fast as the Go compiler compiles Go. Both compilers were written by Ken Thompson.
It is marketing, because it is sold as Go was the first language to have such fast implementations, which is not the case, but many refer to Go as if it was the first language having such a feature.
Nobody ever claimed Go was the first language with a fast compiler, it was simply claimed that it builds much faster than C++ and Java.
There are compilers faster than the Go compilers in terms of lines compiled per second. Even Python parses code faster than the Go compiler, however, Go builds large, real life projects, faster because it is the only implementation that scales linearly with the number of components, other scale O(n^2)
Turbo Pascal, Modula, and Ada, which you bring into discussion may have had fast compilers, but the build process was still O(n^2), not O(n).
A fast compile time is one of the stated goals, is it not? I ask because this seems like the kind of thing that's hard to do correctly unless it's explicitly stated as a design goal.
This, more than anything else, is what's really got me interested in trying out Go when I have some time! I know it's not the most important thing in the world - my projects are generally such that compile times aren't a huge time suck - but it's still an exciting thought nevertheless.
Recompiling my projects of a couple of thousand lines is instantaneous. It really makes you re-think the classic edit-compile-edit cycle since the compile time is negligible.