[EDIT: I didn't down-vote you, and I appreciate the question.]
Simplicity is not the same as familiarity. It's not the same as a small feature-set, either. Gratuitous Rich Hickey reference for what I mean by simple[1]. So most languages aren't simple by that definition, but I'd say that Go's inconsistencies prevent it from being what I call simple. Some examples:
Instead of having a general mechanism for describing datatypes, they have several one-off, exceptional syntaxes (such as for how you define tyep type of a map).
Go's dependency management / vendoring (or lack thereof) is complexity-inducing, even though it appears simple at the outset.
Sometimes you do things via method (such as `fmt.Println(message)` and sometimes via function (such as `len(message)`).
And so on. Coming from a language like Clojure that is regular, possibly to a fault, Go seemed to be littered with one-offs and inconsistencies.
Simplicity is not the same as familiarity. It's not the same as a small feature-set, either. Gratuitous Rich Hickey reference for what I mean by simple[1]. So most languages aren't simple by that definition, but I'd say that Go's inconsistencies prevent it from being what I call simple. Some examples:
Instead of having a general mechanism for describing datatypes, they have several one-off, exceptional syntaxes (such as for how you define tyep type of a map).
Go's dependency management / vendoring (or lack thereof) is complexity-inducing, even though it appears simple at the outset.
Sometimes you do things via method (such as `fmt.Println(message)` and sometimes via function (such as `len(message)`).
And so on. Coming from a language like Clojure that is regular, possibly to a fault, Go seemed to be littered with one-offs and inconsistencies.
[1] https://github.com/matthiasn/talk-transcripts/blob/master/Hi...