This question was posed to me in the Hemispheric Views Discord the other day. It’s a bit notable that I didn’t have an answer written down for this already, seeing that I do have pretty concrete reasons for why I really like Go. So I figured it was time to write them out.

I should preface this by saying that by liking Go it doesn’t mean I don’t use or like any other languages. I don’t fully understand those that need to dislike other languages like they’re football teams. “Right tool for the job” and all that. But I do have a soft-spot for Go and it tends to be my go-to language for any new projects or scripting tasks.

So here it is: the reasons why I like Go.

First, it’s simplicity. Go is not a large language, and a large majority of it you can keep in your working memory. This makes Go easy to write and, more importantly, easy to read.

It might seam that a small feature set makes the language quite limiting. Well, it does, to a degree, but I’d argue that’s not a bad thing. If there are only a couple of ways to do something, it makes it way easier to predict what code you’re expecting to see. It’s sort of like knowing what the next sentence will be in a novel: you know a piece of logic will require some dependant behaviour, and you start thinking to yourself “how would I do that?” If the answer space is small, you’re more likely to see what you expect in the actual code.

But just because Go is a deliberately small language doesn’t mean that it’s a stagnant language. There have been some pretty significant features added to it recently, and there are more plans for smoothing out the remaining rough edges. It’s just that the dev team are very deliberate in how they approach these additions. They consider forward compatibility as much as they do about backwards compatibility, being careful not to paint themselves into a corner with every new feature.

Type parameters are a great example of this. There were calls for type parameters since Go 1.0, but the dev team pushed back until they came up with a design that worked well for the language. It wasn’t the first design either. I remember one featuring some new constraint-based constructs that did about 80% what interfaces were doing already. If that were shipped it would’ve meant a lot of extra complexity just for type parameters. What was shipped isn’t perfect, and it doesn’t cover every use case type parameters could theoretically support. But it made sense: type parameters built on interfaces, a construct that already existed and was understood.

This, I think, is where C++ fails to a huge degree. The language is massive. It was massive 30 years ago, and they’ve been adding features to the language every few year since, making it larger still. I see Apple doing something similar with Swift, and I’m not sure that’s good for the language. It’s already quite a bit larger than Go, and I think Apple really should curb their desire for adding features to the language unless there’s a good reason for doing so.

The drive for simplicity also extends to deployments. Go is compiled to a static binary, one that is extremely portable and could be easily deployed or package as you so desire. No need to fluff about with dependencies. This is where I found Go having a leg-up over scripting languages, like Python and Ruby. Not because Go is compiled (although that helps) but that you have less need to think about packaging dependencies during a deploy. I wrote a lot of Ruby before looking at Go, and dealing with gems and Bundle was a pain. I’m not a huge Python expert to comment on the various ways that language deals with dependencies, but hearing about the various ways to setup virtual environments doesn’t fill me with confidence that it’s simple.

And I will admit that Go’s approach to this isn’t perfect either. For a long while Go didn’t even have a way to manage versioned dependencies: they were all lumped into a single repository. The approach with modules is better, but not without some annoyances themselves. Any dependency that goes beyond version 1 requires you to change the import statement to include a vX, an unnecessary measure if the version change is backwards compatible. That’s not even considering packages that avoid this, and are forever on version 1 (or 0).

But since moving to modules my encounters with package dependencies issues remains quite rare, and once you’ve got the build sorted out, that’s it. No need to deal with packaging after that.

And I’d argue that Go rides that sweet-spot between a scripting language like Python and Ruby, and a compiled language like C (maybe Rust, but I know very little of that language to comment on it). It’s type safe, but type inferences make it easy to write concise code without excessive annotations everywhere. It’s compiled to an executable, yet memory is managed for you. I won’t talk about how Go does concurrency, but after dealing with Java threads for several years, using them are a joy.

I should probably balance the scale a bit and talk about areas where I think Go could be made better. The big one is error handling. While I do like the principals — that errors are values and can be handled as such — it does mean a lot of boilerplate like this:

foo, err := doThis()
if err != nil {
  return err
}

bar, err := doThat(foo)
if err != nil {
  return err
}

baz, err := doAnotherThing(bar)
if err != nil {
  return err
}

To the Go teams credit, the are looking at improving this. And I think there’s enough prior art out there for a solution that’ll look pretty nice without having to resort to exceptions. Maybe something like Swift’s guard statement, that can be used in an expression.

And yeah, other areas of Go, like it’s support for mobile or GUI-style programming and lacking a bit. That could probably be plugged with third-party modules to a degree, although I think because Go is not an object-orientated language, the seals won’t be perfect (take a look at Go’s implementation of QT to see how imperfect Go maps to a toolkit that assumes objects). And some gaps need to be plugged by Google themselves, like with mobile support (they do have something here, but I’m not sure to what degree they’re being maintained).

But I’m sure most of these issues are surmountable. And no language is perfect. If Go doesn’t work for a situation, I’ll use Java or Swift or something else. “Right tool for the job” and all that.

So these are the reasons why I like Go. And I think it all boils down to trying to keep the language simple while still being useful. And as far as my experience with Go is concerned, those maintaining it are doing a pretty stellar job.