The Parts of Go That I Like

3 Nov 2018

Hey there. It's been almost a year since I've picked up Go language as the main programming language for my day to day work and I think it is time to summarize my experience with it. Since the sole purpose of this summary is to collect interesting ideas regarding programming language and ecosystem design, I will only focus on the parts that I find good and valuable. Other people already did a good job spotting numerous Go shortcomings, so I don't think I can bring anything new to the topic.

Without further ado, here are these parts:

  • Unified code style

  • Composition, not inheritance

  • Rich standard library

  • Thorough documentation

Now let's look at each of them more closely.

Unified Code Style

As a person who doesn't care about having a particular code style in the project, rather some style that is used consistently, I can't say how much I'm satisfied with the gofmt tool. It helps teams to avoid lots of poorly reasoned debates and do their job already. I think that every programming language that is supposed to be used in collaborative development should come with a tool like gofmt.

Composition, not Inheritance

Though I don't think that traditional inheritance-based OOP is worthless, I believe that in most cases composition does a better job than inheritance because it is much easier to reason about. There are fewer things to consider when designing an entity that is supposed to be used exclusively via composition: you need to design only its private and public interfaces. When it comes to inheritance, you also need to consider your "protected" interface; that is an interface exposed to the descendants of your entity. Then there is overriding that I believe also complicates understanding of what happens in the object hierarchy. To sum up, composition might be less expressive than inheritance, but at the same time it is much easier to comprehend and just enough to do the job fine in most cases.

Rich Standard Library

This is a controversial trait, because there are people believing that a programming language should have as minimal stdlib as possible, and I think it's a valid option in some cases, e.g. Rust chose this approach because it will allow using Rust in embedded environments relatively easy. For a more general-purposed programming language, I think it is beneficial to have a rich and well-designed standard library. I remember how cool it was to use only Python to get things done, though Python's stdlib is not what I'd describe as well-designed (httplib, ugh). Well, Go does a much better job here; you can say that by looking at the number of third-party implementations of JSON parsers and HTTP clients for it.

Thorough Documentation

Last, but not least is how Go documents things. I'm talking not only about the code documentation, but also about numerous tutorials and blog posts, as well as tools such as Go playground. They do a really good job of educating people about best practices and right ways of doing things in Go.

Is that it?

Pretty much, yeah. Though Go is far from being my favorite programming language, I think it does a really good job on the things I've mentioned in the post. I might have missed something; I'd be glad if you could drop me a line and mention what do you consider to be a good part of Go and why. Cheers!