When discussing the Go programming language, I find it useful to always reference the goals of the language. Discussion tends to devolve into a comparison of features of other programming languages which Go lacks. Without the context of these goals, the discussion ceases being useful.
Stolen from a Google tech talk that Rob Pike did back in 2009:
Goals
- The efficiency of a statically-typed compiled language with the ease of programming of a dynamic language.
- Safety: type-safe and memory-safe.
- Good support for concurrency and communication.
- Efficient, latency-free garbage collection.
- High-speed compilation.
Watch the Go at Google video or read the article and you will get the impression that these goals are NOT in their order of importance. I suggest that the last item, High-speed compilation, trumps all the others.
Here is a short, 1:15 video demonstrating the speed of the go compiler: https://www.youtube.com/watch?v=wwoWei-GAPo
The first comment, over 2 years ago, at Lambda the Ultimate, about that Go at Google video, sums it up even better. It is a snapshot of another slide. This time instead of Go goals, the slide is “What makes large-scale development hard with C++ or Java (at least):”
- slow builds
- uncontrolled dependencies
- each programmer using a different subset of the language
- poor program understanding (documentation, etc.)
- duplication of effort
- cost of updates
- version skew
- difficulty of automation (auto rewriters etc.): tooling
- cross-language builds
* Language features don’t usually address these.
It took me quite a while to keep these above things in mind when thinking about Go. In fact, I still tend to compare Go to my favorite programming languages, probably because I often forget some of those above drawbacks to C++/Java (read C# for me).
I’ll try to remember. I beg others to try to remember too.