Problems with Go channels (2016)

Unlike the author, I would actually say that Go is bad. This article illustrates my frustration with Go very well, on a meta level.

Go's design consistently at every turn chose the simplest (one might say "dumbest", but I don't mean it entirely derogatory) way to do something. It was the simplest most obvious choice made by a very competent engineer. But it was entirely made in isolation, not by a language design expert.

Go designs did not actually go out and research language design. It just went with the gut feel of the designers.

But that's just it, those rules are there for a reason. It's like the rules of airplane design: Every single rule was written in blood. You toss those rules out (or don't even research them) at your own, and your user's, peril.

Go's design reminds me of Brexit, and the famous "The people of this country have had enough of experts". And like with Brexit, it's easy to give a lame catch phrase, which seems convincing and makes people go "well what's the problem with that, keeping it simple?".

Explaining just what the problem is with this "design by catchphrase" is illustrated by the article. It needs ~100 paragraphs (a quick error prone scan was 86 plus sample code) to explain just why these choices leads to a darkened room with rakes sprinkled all over it.

And this article is just about Go channels!

Go could get a 100 articles like this written about it, covering various aspects of its design. They all have the same root cause: Go's designers had enough of experts, and it takes longer to explain why something leads to bad outcomes, than to just show the catchphrase level "look at the happy path. Look at it!".

I dislike Java more than I dislike Go. But at least Java was designed, and doesn't have this particular meta-problem. When Go was made we knew better than to design languages this way.

Go's designers were experts. They had extensive experience building programming languages and operating systems.

But they were working in a bit of a vacuum. Not only were they mostly addressing the internal needs of Google, which is a write-only shop as far as the rest of the software industry is concerned, they also didn't have broad experience across many languages, and instead had deep experience with a few languages.

I guess we're going into the definition of the word "expert".

I don't think the word encompasses "have done it several times before, but has not actually even looked at the state of the art".

If you're a good enough engineer, you can build anything you want. That doesn't make you an expert.

I have built many websites. I'm not a web site building expert. Not even remotely.

I think both C and Go (the former is relevant due to Thompson's involvement in both and the massive influence it had on Go) are very "practical" languages, with strict goals in mind, and which delivered on those goals very well. They also couldn't have existed without battle-tested prior experience, including B for C and Limbo for Go.

I also think it's only from the perspective of a select few, plus some purists, that the authors of Go can be considered anything other than experts. That they made some mistakes, including some borne of hubris, doesn't really diminish their expertise to me.

But my point is that articles like this show how that if you don't keep up with the state of the art, you run the risk of making this predictable mistakes.

If Go had been designed in the 1980s then it would have been genius. But now we know better. Expertise is more than knowing state of the art as of 30 years prior.