I've seen pretty convoluted code bases otherwise that showcase the engineering muscle of the individual and how they can employ almost every single language feature even to a very narrow business domain.
That is an assertion which makes no sense to me. Go is not a minimalist language, it's a restrictive one. Although it made different choices, it's in the same vein as Java, and certainly no Forth, or Smalltalk.
> It is hard to over engineer when there's no inheritance, no meta classes, no properties, iterators, decorators and such.
None of that has anything to do with over engineering?
Not to mention, if you every spawned a container, there are 99.9% chances that somewhere go was involved along the way. There are other run times around (rust comes to mind) but none is production ready.
Point is - restrictive should have restricted. It hasn't
Minimalist isn't restrictive.
EDIT: Added docker and restrictive not the same as minimal.
The language is restrictive, in that you can't "play" with the language, it has a very fixed syntax / structure and no real way to make your own, much like Java or C#: no macros, limited runtime reflection (to say nothing of wholesale manipulation), control structures are heavily syntactic, etc...
Hell, the designers built in a bunch of collections and behaviour (and special syntax) around those collections because they either did not want to or could not be arsed to make the language able to express them.
> Whole cluster orchestrators have been built with go (k8s, nomad), whole databases have been built with go (cockroachhDB), whole authentication systems have been built with go (zitadel, authelia), whole web servers have been built with go (Caddy, Traefik), whole DNS servers have been built with go (CoreDNS), whole key value stores have been built with go (etcd), some encryption has been built with go (age) so how it is restrictive and why didn't it restrict all those use cases?
That has nothing to do with anything? Literally all you're stating is "the language is turing complete therefore it can't be restrictive".
> Minimalist isn't restrictive.
No, it's not. And neither is the reverse.
And go is restrictive, not minimalist.
Most over-engineering in the wild overuses inheritance. That's why we see more monstrous "enterprise" code in Java and C# than languages like Go and Rust that lack inheritance.
Rust has a completely different niche, and maybe wait a bit before claiming anything like that about Go - it is not being used for that kind of enterprise systems just yet.
You're not making any sense, and you're not providing any sort of argument either.
The flexibility of the language and its syntax. The more constructs are syntactic, the less minimalistic it is, and Go is a very syntactic language.
> I've always considered Go to be minimalist in terms of available tokens to the programmer: https://github.com/e3b0c442/keywords/blob/main/chart.png
No language on this chart has even a passing resemblance to minimalistic. I don't think anything does when it reaches double digit keywords.
For reference, I believe Smalltalk has 6.
And forth is more complicated because it doesn't really have keywords at all, and barely any syntax, instead it has assembly-coded / runtime-provided words (~functions) and variables. SectorForth (https://github.com/cesarblum/sectorforth/) is down to 8 builtin words, 2 IO words, and 5 variables (milliforth packs those behind a word instead). And so far 2 of the words have been found unnecessary / redundant.
I've been programming in Go professionally for 6 years, and it covers 80% of usecases well, but that last 20% is really tricky
And because this is HN, I have to mention of course you can over engineer current Go as well. But it's not "fun".