TEXLUTION

TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community.

Absolutely everything in life are trade-offs, the first law of thermodynamics makes sure of that, and programming languages are no exceptions. Go’s trade-offs are not unique, but it’s a good set of trade-offs and thanks to them, Go is happening. But the laws of physics also state that for every action there is a reaction, and with the rise of popularity there is also an increasing amount of criticism, some IMO more valid, some IMO less so. Let me try to explain you why I think it doesn’t matter, and Go will succeed no matter what.

Raison d’être

To understands why Go is the way it is you need to know why it came to exist in the first place.

The goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable. The language was designed by and for people who write—and read and debug and maintain—large software systems. source

That’s why Go was created, nothing more. It was not a fun 20% project that caught momentum. It was not to achieve something that couldn’t be done before. It was simply created out of the frustration of dealing with the complexity generated by very large teams of people working on very large pieces of software written in languages with large feature sets. Every trade-off was chosen because it follows those interests, if you are not happy with the trade-offs, it most likely means your interests don’t align, and you shouldn’t be using Go.

While it has great features like compilation speed or easy concurrency, the main feature that makes Go special is its extreme simplicity. Go tries to reduce the complexity at Google’s large projects at all costs, and it does so by sacrificing things, lots of things, sometimes even principles that you thought untouchable like DRY. Go is not like python or ruby, which “allow” you to write understandable code. In Go you basically have no other choice.

To put it more graphically. Go is your friend, but not your friend at a party asking you to take a taxi back home, Go is your friend at an intervention telling you that he’s thrown all the alcohol out of the window. Go won’t let you abstract yourself in the foot.

Other trade-offs are orthogonal. Yes, it won’t always keep you safe from data races as Erlang will, but Erlang keeps you safe by copying your data over and over, making it significantly slower, TANSTAAFL.

I, the critic

When you read a critic, and this applies to many other subjects, you can usually divide them into 2 categories:

1. Complaining about Go not optimally achieving Go’s design goals
2. Complaining about Go not optimally achieving personal goals

Now, there are some valid critics out there that fall in the first bucket. Sometimes it’s a matter of opinion. Sometimes things are technically more complicated that people assume. Sometimes the Go authors, human beings as they are, just didn’t get it completely right.

Many critics I find though, fall into the second bucket. The answer to those critics is always the same: “Go is just not for you”. Some people see this attitude as stubbornness from the community, aversion to improve which will doom Go in the long run. They just don’t realize that some people want different things.

A very easy way to spot these misalignments of interest is analyzing the use of the word “I”. They tend to be frustrated because “I” can not do what “I” want, “I” can not express this how “I” want. It’s not often that you’ll see complains about what “we” do.

If what frustrates you is pulling your head trying to understand how something works after 5 very different people worked on it at different points in time, or even if it’s something you wrote yourself in the past, then Go is for you. If what frustrates you is not being able to use ClojureScript code tricks then Go is not what you are looking for. If what frustrates you is not being able to distinguish yourself as smarter than the rest, then Go is definitely not for you.

Open source

Aside from personal preferences, there is one group that undeniably benefits even more than Google from Go’s simplicity and approachability, the open source community.

Open source projects live on contributions. Very few successful projects are built only by a single developer. In the open source world you don’t recruit your contributors, they must come to you, and while you can chose which contributions to accept, the more you get the stronger you grow. This is where a level playing field like Go thrives.

Go shines particularly in 3 aspects:

It invites to look under the hood

If you are like me, you’ll find yourself quite often looking at projects on GitHub. Either out of curiosity or need, many times you’ll look at the actual internals trying to see how everything works. Sometimes you’ll find the code simple and easy to follow, other times you’ll find layer upon layer to decipher. Go projects tend to overwhelmingly fall on the easy side.

Even if I don’t have to touch the code, I personally always tend to favor using certain OSS because of the simple fact that it’s written in Go makes me feel much more in control over it. I feel like in case of problems I don’t depend on the creator to fix my issues. I don’t have the same feeling with projects written in languages that I’ve been using for much longer. For OSS projects, being written in Go is a feature in itself.

It makes accepting contributions easy

The level playing field it’s also hugely beneficial from the creator’s side. Go makes reviewing merge requests much less tedious. Tools like go fmt, golint and go vet leave very little room for any personal coding standard. And in general Go won’t easily let your project become frankensteinian with a thousand ways of doing the same thing. If you have to review code from random people from the internet, you don’t want a language with tricks or most likely you don’t want people to show off how smart they are. You want something explicit and obvious. Maybe even with a local approach to error handling.

It mitigates open source stage fright

It’s a well known issue that if you take the step of open sourcing something you need to either be a rockstar programmer or have a rockstar ego to stand the critics. It doesn’t really matter how good is what you write, there is always someone who will hate it and will make sure to tell you. This is bad for putting under stress good people doing altruistic work, but it also keeps lots of source code in the dark because the authors fear that it’s not good enough for the open source stage.

Go code tends to look ready for the public much sooner than most other languages, it provides a much stronger feeling of comfort to the developer, and the community embraces small-simple solutions over big-“sophisticated” ones. In general Go dilutes a lot of developer insecurity bringing proportionally more code out of the dark.

Closing thoughts

This open source fitness is why I think you are about to see more and more Go around in spite of what some might think of it. In fact, Go has already succeeded. Much of the meaningful systems software coming out these days is written in Go. OSS companies like docker, CoreOS or HashiCorp are leading a server revolution with Go as their primary tool. You have emerging databases, search libraries, http proxies or monitoring systems. Go is already a big player in server software and it’s only extending its reach.

If you have complaints about Go not optimally achieving its design goals, however valid, accept that they won’t change anything. The Go team has said time and again that the language is done for the foreseeable future. You are too late to the party. Some might cry about this, but this stability promise brings more long term benefits than any language improvement could. Breaking changes, even if for the better, are not always welcome, not even in the wild wild west of javascript development.

What if you really like the simplicity but there are a couple of other trade-offs that just suck for you? Then I’m really sorry, you can either keep searching for a language that perfectly suits your needs, or if you have the skills create your own language. Who knows, if enough other people have the same needs it could even get some traction.

Update Jun 14, 2015

Looks like the article has made a bit of a splash. It received around 40K visits during the first 24 hours, and I’ve got quite some feedback, both direct and indirect. I won’t go into arguing with the internet but it’d like to make a couple of late remarks for whoever stumbles upon this on future times.

On the meaning of success

By success I don’t mean that Go will replace every other language in existence. That’s silly. By success I mean it will be a significant part of most developer’s life, if not directly programming in Go, at least using software built with it on a regular basis. That’s my understanding of a successful programming language.

On proving my claims

This article was originally posted to the Golang subreddit, and it was intended for an audience already familiar with the language. Proving that Go code is indeed so simple and easy to maintain is beyond the scope of the article and AFAIK that’s not in debate anywhere. My claims can seem obvious to people who have used Go and total propaganda to people who don’t know anything about it.

I’m not competent to formally prove Go’s accomplishments regarding simplicity. I only experience them. If you really want to know if my claims are true I’d recommend you to just take the Go tour and browse around Github’s Go repos. I’d also recommend you to take a look at Rob Pike’s less is exponentially more, where he lists and discusses some of Go’s simplifications.