Go is faster than most languages so I'm not sure it's related to the recent CPU since every languages are benchmarks against the same CPU.
"The complete lack of push/pop instructions also shows a massive defect in the understanding of how the x86 architecture is supposed to be used."
I'm sure the Go team has very skilled people in that field, so I'm not sure what you mean.
You have to understand that the Go compiler does not look for the best optimized code, it's a balance between performance / compile speed and "debuggability".
> You have to understand that the Go compiler does not look for the best optimized code, it's a balance between performance / compile speed and "debuggability".
Passing arguments in registers doesn't help "debuggability". There is a debugging advantage to not using registers at all (though there really shouldn't be; spilling all locals to stack for -g -O0 is only necessary due to design problems in LLVM). But there's no debugging advantage to having a calling convention that spills everything on stack. If you your debugging infrastructure can handle locals in registers at all, it can easily handle arguments in registers too.
People who have wrote some successful language are not necessarily "world class compiler and GC experts", and it's even less correlated with "having kept up with the last 30+ years of PL research" as mentioned above.
Would you call e.g. Kernighan or Guido "world class compiler and GC experts", compared to people like Anders Hejlsberg, Lars Bak, Martin Odersky, Wirth, Simon Peyton Jones, Lattner, and co, who are experts devoted to exactly PL (and don't miss real-world accolades).
Robert Griesemer might come close, but he doesn't appear to be the driving force.
Even more importantly, does Go strike you as the product of "PL expertise", or just a competent, pragmatic, if humble, compiler, the likes of which are many (and even more full featured, even from smaller teams)?
What I see Go having more is adoption and libs (probably due to Google's full-time dev support and branding). Not some PL upper hand over other languages like Rust, Crystal, Zig, Nim, etc.
I don't know any compiler from smaller team that matches the Go one, it's one of the reason why people use Go, compiling things is fast and easy, from my raspbery pi I can compile a win10 64bits exec with 0 problems 0 tools to install. ( ex: GOOS=windows GOARCH=amd64 go build . )
None of those are arguments for "PL experts" as none of those are specifically signs of superior PL expertise.
Multiple platforms for example are mainly about adoption (and not having much optimizations/assembly parts in the codebase, making it easier to port).
Fast compilation is something several languages manage. And being fast to compile because you don't do much (in the way of optimizations) is something most languages can manage.
"No dependencies" is also about adoption and resources (to replace popular dependencies). Nothing particular related to PL/compiler expertise about it.
Go never had a "good debugging" story, and it doesn't have the best performance either (e.g. compare with Rust, D, Crystal, etc). In certain areas like text processing it's even worse.
Richard Hudson, Ian Lance Taylor, David Chase, Austin Clements. The team is incredibly skilled.
And of course Pike, Griesmer & Cox.
I think that they are well aware of the trade-offs they make. And I also think that it is quite arrogant to say otherwise just because your tastes are different.
Go ahead, please write the go haters' handbook. Or write rants saying 'go is obsolete'. And the future will say who has a viable legacy.
"The complete lack of push/pop instructions also shows a massive defect in the understanding of how the x86 architecture is supposed to be used."
I'm sure the Go team has very skilled people in that field, so I'm not sure what you mean.
You have to understand that the Go compiler does not look for the best optimized code, it's a balance between performance / compile speed and "debuggability".