> Yeah it's hard to write weirdly complicated code in Go
Just because Go lacks many forms of abstraction, doesn't mean complex code will not be created with it. Quite the opposite. It's lack of expressiveness will encourage "frameworks", elaborate encodings, code generation and various productivity aids. Look at what the lack of generics has done to the Kubernetes code base:
"The core team replaced a compile-time language feature that was missing (Generics) with their home-built runtime system"
> What you see in K8S is the exception rather than the norm in Go - but is the norm in other languages.
I suggest that is because not many large applications have yet been built in Go and it is still relatively young. If Go was used more sparingly as a "domain-specific language for concurrent network services", then I might be inclined to agree with you, but it seems to be marketed and promoted as a general purpose language.
Go is over a decade old and basically powers the majority of web infrastructure right now (k8s, docker, traefik, istio, terraform, cloudflare) and is used by google, Uber, twitch, SoundCloud, dropbox, YouTube, sendgrid... these are not exactly backyard projects. 90% of all software written falls into concurrent network services now.
Kubernetes is infamous for being one of the worst examples of a Go codebase in the community. And that proves my point really, this codebase sticks out like a sore thumb because it's no idiomatic Go.
Just because Go lacks many forms of abstraction, doesn't mean complex code will not be created with it. Quite the opposite. It's lack of expressiveness will encourage "frameworks", elaborate encodings, code generation and various productivity aids. Look at what the lack of generics has done to the Kubernetes code base:
"The core team replaced a compile-time language feature that was missing (Generics) with their home-built runtime system"
https://medium.com/@arschles/go-experience-report-generics-i...