Go's domain is CRUD microservices, for which abstraction is generally distraction. If that's all you use it for, of course you are going to like it.
What's dispiriting here is that there are cogent arguments against Go --- decisions Go could have made differently that probably wouldn't have cost the project much in terms of its other goals of compilation speed and simplicity, but make it more annoying to work in. I switch between Rust and Go every day and miss pattern matching almost every time, for instance.
Instead, though, we get the same dumb innuendo. "It's a language for managers". "It's a language for CRUD apps". "It's a language for junior programmers". Never mind that the kernel of truth in those statements is shared by languages like Python; you can't really get away with trashing Python like that, or you'll be haunted by the ghost of one of Peter Norvig's terrifying shirts. Which is a way you know not much is really being said here, except that there's some weird turf war between Go and whatever language its haters are advocating for.
I've recently tried using it as a "better shell script for gophers" but it's still too early to say.
We've all heard the nulls, pattern matching, etc arguments already. I just think it's not that big of a pain if you are only doing CRUD and that's why it makes sense in its domain.
EDIT: I've fallen out of love with Python because it's bad at large programs (distributed or not). Didn't think that's controversial.
This is too close to my work life that I don't wish to comment on this project. EDIT: but it is a fantastic accomplishment
Go can get you good performance on a CRUD app, but that's probably the only advantage you'll get. On the other hand, Go doesn't have the facilities to build the frameworks that make CRUD apps so easy on languages like Java, Ruby or Python.
Go is a much better domain fit for microservices that don't do CRUD, for server and network control plane (k8s, istio, docker), configuration systems,CI/CD tools. So many things that are definitely not CRUD.
As a side note: People love to vilify CRUD apps, but they also require skill to do right. I've seen way too many botched attempts that ended up expensive to maintain and an absolute performance disaster.
To use wikipedia's definition of CRUD, "[CRUD] are the four basic operations of persistent storage." etcd is persistent but a DMA ring is not?
But fundamentally the main way k8s resources are implemented is by observing the current state and desired state and updating the current state to be closer to the desired state, sometimes performing other actions (which are often updates on a different resource's setting)... so whether "other actions" are enough to make it not-CRUD is to the eye of the beholder.
Perhaps, it's hard to argue that a data serialization format is worse than previous alternative approaches (OLE?), but specifically a schema-less one should be up for debate? (Clearly I've become a protobuf, um, fan? Might be a bit far)
The code I write is adjacent: refactoring the tests so they run faster with less flakiness (guess what Go makes extremely annoying: mocking concrete types from dependencies! You must either wrap it in your own code (and continuously, manually, maintain that abstraction), give up, or alter the upstream) and writing internal services and tools. Tools are primarily in Go so we can share libraries.