Month: December 2014

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.

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