When is Go a nice language?

30 May 2019

I’ve been following Go for a while due to the influence of one of my personal heroes: Ken Thompson (due to his hand in making Unix and C programming language).

Many years ago I met Douglas Crockford. At that point I was looking into low level implementation of parsers why I suggested a JVM language with more primitive structures in order to simplify implementation of more low level performance critical parts:

The comment was in a way prophetic since that’s sort of what has happened with Go.

The good

Very procedural

Go fits procedural programmers naturally: Since many programmers start out thinking procedurally and debugging code in order to understand it, it should come naturally to many developers.

There are few conceptual components of Go. Like C, it’s not really a difficult language to learn (though there are some constructs related to goroutines that looks like false friends).

Simple reflection

There are rudimentary reflection capabilities, why you could implement some standard meta programming patterns found in Java/C#.

Compilation time

Go has short compilation time. This can improve developer happiness (reduce the code/compile/try cycle). It is also easy to use in non standard editors (as opposed to c#/Java).

Size of docker deliverables

Compared to some other more mature languages like c# and Java: Go produces smaller docker deliverables. Though if you really care about the size of your deliverables Go might not be the optimal language (but perhaps good enough).

Code formatter

I like that Go comes bundled with a code formatter, since c languages otherwise leans towards bike shedding when it comes to formatting.


There is a nice story around testing for the language that also could improve developer productivity.

Structural types

In order to implement an interface you use the fact that Go has a structural type system.

The bad

Rudimentary type safety

When dealing with large code repositories I’ve found that it is generally preferable to have the compiler assist you. You can get away with a looser type system by adding enough tests and being very meticulous.

Missing parts

One of the notable things in Go is that there are no exceptions. This is however a half truth. Note for instance Matt Kleins post on Medium, about how you can get around this limitation in a way perhaps frowned upon by the designers of the language.


The error handling and lack of generics require you to write more code. The performance is comparable to other statically typed languages. My guess is that you can be productive enough in order to write regular business code in it. It can be used as an alternative to Java and C# for when the team likes Go-style code.


Comments or errors? Fork this post and do a pull request on github