I sympathize with your sentiment, but I don't think Go has anything to do with this.
The disregard for the fact that some engineers are more productive than others originates from companies' processes and planning. Projects are usually estimated without considering who will be working on the project and individuals are compressed to person-weeks. I have experienced it myself and read texts describing this issue in the same terms[1].
It doesn't really help that Go was designed in such a company, but saying that it was designed to mitigate this disparity is saying that the best predictor of an engineer's productivity is the number of LOC cranked out. I don't think that is the case, neither in principle nor in Google particularly.
Much better predictors of productivity are effective communication and conceptual integrity of the design, as the linked article points out. It doesn't really help that you use brilliant language if, 6 months in, you've realized you're building the wrong thing, or you build it in the wrong way.
In the end, Go is indeed effective at making engineers avoid arcane and difficult code, but doing the "difficult" stuff that's not available in Go is definitely not how the most productive engineers are productive.
IMO, someone making code that abuses special features to the point it is difficult for other members (including future members) of the team to read is the definition of a negative-X programmer. Unless they're working solo, of course.
Also, like wavesbelow mentioned in his great comment, the "10x" doesn't come from coding prowess alone: it starts long before that, with the process and planning.
I get the assomption that with go you will avoid 0.2 programmers and make everyone a 1x programmer. But for me, a 10x programmer can generate complex, well engineered systems with a reasonable structure, not by writing everything in low level, super hard code ? From the level a 10x programmer might operate I'm not sure the programming language would be that important ? Expressivity is nice and some languages are better than others, but from my experience you can write nice artifacts from plain tools?
> a 10x programmer can generate complex, well engineered systems with a reasonable structure, not by writing everything in low level, super hard code ?
Yeah maybe, but I'm certainly not at that level.
If a 10x programmer exposes foo() and bar() methods to me, I'll call foo().bar() and not realise I've made a mistake, or that I've violated some invariant that's only in his head, not in the low-level code itself.
The disregard for the fact that some engineers are more productive than others originates from companies' processes and planning. Projects are usually estimated without considering who will be working on the project and individuals are compressed to person-weeks. I have experienced it myself and read texts describing this issue in the same terms[1].
It doesn't really help that Go was designed in such a company, but saying that it was designed to mitigate this disparity is saying that the best predictor of an engineer's productivity is the number of LOC cranked out. I don't think that is the case, neither in principle nor in Google particularly.
Much better predictors of productivity are effective communication and conceptual integrity of the design, as the linked article points out. It doesn't really help that you use brilliant language if, 6 months in, you've realized you're building the wrong thing, or you build it in the wrong way.
1. https://danluu.com/people-matter