I dislike Go. I dislike it a lot. Nevertheless, I usually do not bash on it because I am deeply convinced that people should use whatever they want and they like. Many people I respect use Go. I mean, this blog run on Hugo, that is written in Go! How could I be one of “those guys” who always bitch about what other people enjoy?

However, sometimes, I fall into watching discussions in the go community, and they are so absurd I cannot shut up. 

As you probably know, Go 2.0 design contains some experimental implementation of a proposal for generics. People like me, when we first got this news collectively shouted: “Finally!”.

You may think: “That’s a good thing! What’s the problem with that!” Well, the problem is that there are still discussions about that. Watching this in 2019 is overly cringe. For instance, look at this blog post, posted on the Go’s blog on the 31st of July.

When I read it, I put the hands in my hairs. That is an actual article from 2019 discussing a problem that is practically closed since 1973.¹ The whole article looks like the Go’s maintainers just landed from Mars, bringing us their novel idea!

Well, it is not. As I said, the problem of maintaining strong-types and compile-time validation of generic code is closed for 50 years.

I know why they need to do that. For the last 8 years, everyone in the Go community was trying to sell us why the lack of generics code was a brilliant feature, and not the design flaw it is. Therefore, they now need some time to sweep everything under the carpet by presenting their solution as if they just found it! It does not matter if everybody else was suggesting that since 24 hours after the first release of Go!

Oh, well. They already pulled this move. Remember all the “Go does not require a dependency manager!”, and then everybody asked “are you sure? It seems a problem.” And they answered “Sure!”. How is it ended? Like this.

So this is my main problem with Go: I do not trust it. Everything in Go reminds me of those junior developers claiming that the legacy code is “too complex.” Then the junior devs start writing a simpler version, only to make it complex again as they realize why the code was complex in the first place!

Again, this is not against the Go users. They do Wonderfull things with it despite the limitations. However, Go maintainers are wasting the time of such wonderful developers by fighting against the essential features that a language designed in this century should have from day one. Because, at some point, they may realize there are many languages designed in this decade that are worth exploring.