Three Months of Go from a Haskeller’s perspective (2016)

I have never gotten it. I find Go code somewhat easy to write, just just give up on trying to be concise or elegant, but not at all easy to read. The excessive boilerplate just makes me feel like my brain does not have the working memory to piece it all together.

The constructs are simple, true, but if you are trying to write anything non-trivial, then simple syntax will not make your problem simpler. It is just expressed in tens of times more lines than in Elixir, Haskell or even PHP. This takes a toll on the reader.

As an example - you can accomplish interesting projects with Lego. And it is easy to get going for sure. But at some point, when you are trying to do something non-trivial, it becomes a hindrance, despite it's simplicity. Hence "I built a life-size XYZ in Lego" becomes impressive in it's own right.

Oh, and Go modules is a story of a train wreck.

"Use it more" is not an answer. If you have found a good way to produce software and it has served you well -- even better if you had other ways in the past and your latest one is objectively better! -- then you are not under any obligation to "give it a chance".

Many people longed for certain ways of doing things and one day they found the tools that enable them. That's quite fine. No need to insert platitudes in there which can't ever be satisfied (like "use it more", especially if you are not inclined to).

The world record 100m men's sprint for double-leg-below-the-knee amputees is now frozen at 10.57s (record set in 2013); omitting Usain Bolt who is clearly freakishly good even among world-class sprinters, the 100m world record is 9.74s.

I am very happy to use strong static type systems.

I was a C# developer writing all these abstractions like every other C# developer does. It's idiomatic C#. OOP exists, you're encouraged to use it to abstract and decouple code.

Even if you try and strip all that away, you'll never escape it because every library you depend on is written this way. For example, try understanding https://github.com/protobuf-net/protobuf-net like I once did. The cognitive load is huge.

This is C#, this is what having a huge toolset results in.

A simple language with simple code isn't a shortcoming. It's an advantage. Overly complex code is a shortcoming.

I liked writing heavily abstracted code in C#, that's what I used to do every day. But I never liked reading other people's code because without the intimate knowledge of the code it is a huge mental load. Onboarding new developers into a code base they are unfamiliar with is also very time consuming.

In Go I realised that the only abstraction you need is an interface. There's no "abstraction first" mentality like there is in C#. You can define interfaces at any point in time, whereas in C# you must define an interface first, and if you don't then you end up going the OOP route with more abstraction.

And because of this small toolset, reading other people's code is easy. It all looks the same.

I would like to use Go, Haskell, Rust or whatever that I like (or my team as well) but this is just one piece of the whole cake IMO.