In all seriousness, it feels like go's reputation of simplicity is at odds with its design. Instead of making a simple and highly generalized core from which anything can be composed, it has a specialized, familiar core that engineers are comfortable with.
When I take this question further, I begin to wonder why we even use text syntax for programming. What if we just had a graph structured programming "language" that is edited indirectly through different projected syntaxes that aren't necessarily monospaced text. Almost like lisp, but translated into different frontend languages, potentially graphical. (Maybe off topic but whatever)
You can do that but the cognitive overhead of understanding what code is represented becomes more of a burden than the burden of producing logic that is correct and fulfills requirements. You can see part of this in lisps where the arguments of many functions form their own de-facto languages. Then you are not only writing code, but writing it in a variety of different languages that share only a common syntax.
The thing is, I've never found this to be a huge issues in lisps: partly because plenty of languages have libraries that are essentially the same sort of thing, but less ergonomic: Spring/Hibernate in Java, Spark and the various FP stuff in Scala, Ruby on Rails, React. Any sufficiently complex library is essentially an embedded language that must be learned in addition to the base language: the cost of learning a language made out of macros isn't much different from learning a library with a large API surface area.
In fact, since macros reduce the noise in the "language" a library implements, I've generally found that macro-based libraries are somewhat easier to learn than libraries in other languages.
A carefully designed library that introduces a small set of coherent concepts can make good use of powerful syntactic abstractions and result in readable and succinct code.
But application code that implements a large number of one-off requirements is far harder to read if you cannot rely on fixed semantics of basic syntactical elements.
The usual response to that is to say that we shouldn't restrict the features available to good developers just because bad developers might abuse them.
But this argument is flawed. If you read syntax that can be overloaded then you have to account for the possibility that it actually is. It's the possibility that creates the mental burden, not the fact.
I think the solution is for languages to provide a basic set of syntactical elements that cannot be overloaded and are sufficient to write all code. Additionally, there should be optional syntactical elements that can be overloaded even to the point of creating DSLs.
The important point is, there has to be a local cue that tells you whether or not you have to watch out for redefined semantics.
In all seriousness, it feels like go's reputation of simplicity is at odds with its design. Instead of making a simple and highly generalized core from which anything can be composed, it has a specialized, familiar core that engineers are comfortable with.
When I take this question further, I begin to wonder why we even use text syntax for programming. What if we just had a graph structured programming "language" that is edited indirectly through different projected syntaxes that aren't necessarily monospaced text. Almost like lisp, but translated into different frontend languages, potentially graphical. (Maybe off topic but whatever)