When did go get abstractions? (Only half joking)

Isn’t the entire language designed explicitly to prevent programmers from building their own sophisticated abstractions that could confuse other programmers who don’t understand that other persons code… as I understand it, if you can read go and understand basic programming you should be competent with go, and if you know your algorithms you should be proficient.

I hated old Java but the modern language isn’t as bad now some people have added some better syntax shortcuts the libraries are nearly twenty years more polished, and the IDE can nearly half write my code for me so the boilerplate and mind numbing aspect isn’t so bad… I loathe go because using it feels like programming with my hands tied behind my back trying on a keyboard with sandpaper keycaps, despite that, I didn’t bother “learning” go, I could just read it based on my Python/C/Basic/Java/C# experience instead of needing any extra learning.

K8s just so happens to be coded in Golang. A quick look at that overall codebase should be enough to disabuse people of this notion that Golang developers cannot possibly come up with confusing or overly sophisticated abstractions.

Maybe because k8s was originally written in Java ;)

My experience with reading Go is that the language not giving tools to build good abstractions has failed to stop developers from trying to do so anyway. There's never a line of code where I just plain don't know what's even going on syntactically as some languages can have, but understanding what it's actually doing can still require hopping through several files.

In short: a simple (programming) language does means that every small part/line is simple. But it doesn't mean that the combination of all parts/lines is simple. Rather the opposite.

Very true! I think a lot of the accidental complexity of early Java systems were rooted in the not so powerful language. If the language is too powerful (like Scala 2) developers do insane things with it. If the language is not powerful enough, developers create their own helpers and tricks everywhere and have to write a lot of additional code to do so.

Just compare Java streams with how collections are handled in Go and scratch your head how someone can come up with such a restricted language in this century.

> and have to write a lot of additional code to do so.

And most importantly: you have to read a lot of code like this, and understand it's assumptions, failure modes, runtime behavior and bugs, which are different every time. Instead of just reading "ConcurrentHashMap", and be done with your day.

Eh, not really. Go’s philosophy around abstractions is quite poor. Duck typing begs engineers to create poor abstractions that simply reading a codebase does not necessarily lead to understanding. The bolted-on generics implementation actually makes this worse.