A first look at the Go programming language

2017-01-12

It's not easy to keep up with new developments in IT, especially when you work long hours, or for that matter when you no longer learn quite as easily as you used to when you were twenty. So far I was lucky to pick my technologies well: expertise in Python, HTML5 and even Java (for now) has only grown more marketable in recent years. It still felt like falling into a rut as of late, and moreover I kept stumbling across projects written in the Go programming language. After some hesitation, I decided to take the plunge, and it turns out I can still learn a new programming language in a couple of days. Go me!

And what a language it is.

Go is mostly targeted at server-side software, which makes it less relevant for games unless you're doing multiplayer. Then again, it's just as good for command-line apps (think tools), and there's a healthy choice of libraries for text-based user interfaces that don't require separate DLLs.

But what's it like, exactly?

I'd say Go is an odd duck of a language, except it's more of a platypus. Good to see programming language designers having some guts, after decades of slavishly imitating C.

In the way of downsides, the elephant in the room is of course the lack of proper exceptions, which just seems odd for a modern programming language. But look at it this way: in a compiler, is a source file with syntax errors really an exception? Is it truly unexpected? I'd say it's business as usual. Too many programmers use exceptions as a crutch, and don't even get me started about doing flow control with them. The real problem here is code becoming verbose and muddled when you have to check for errors at every step. But hey, at least exception haters can shut up now and enjoy their absence.

A smaller problem is the lack of assertions, which are really useful in the 1% of cases when you really want to assert something instead of simply checking, and other quibbles are surfacing during work: I keep forgetting to create variables instead of simply assigning to them, since it's a slightly different operator, or to propagate errors properly when I'm not dealing with them on a local level. I also keep expecting automatic semicolon insertion to bite me in the behind like it tends to in Javascript, but it hasn't happened yet, so there's that.

Upsides are more numerous and important. Fine-grained numeric types for performance tuning. A static type system that doesn't get in the way. Type inference. Dynamic typing on request via the empty interface and type assertions. (How many other languages have type assertions? Only C++, and only for templates -- through various kludges.) It's not as good as generics, but it provides a lot more flexibility than critics of the language like to claim.

Moreover, the language is small and clean. It took me one afternoon to take the official tour, and another day to half-read, half-skim a textbook -- Learning Go if anyone's interested. The next morning, I was able to code a "Hello, world!" correctly from memory on first try, and two days later I'm already productive. Compared to the intricacies you have to learn before even trying to use C++, for instance, or the overwhelming size of the Java standard library, this is a breath of fresh air. Most documentation does seem to omit useful details, such as multiline strings and function argument unpacking, but the reference manual has you covered.

I'd draw a conclusion, but it's too early before completing even one project successfully in Go. That said, unpleasant surprises seem unlikely at this point, and now I have another tool on my belt, one that opens up new opportunities. Take a look.