Note that Go was invented to address a very specific socio-economic issue that Google was facing.
Go's simplicity is syntactic. The complexity is in semantics and runtime behavior. It is an economic trade off. A language with a 'complex' syntax, such as Rust, is intimidating to the novice and presents a problem of how to 'integrate' a newbie with an evolving codebase written by old hands.
It is true, imo, that ultimtely, the initial cost haircut exacted by languages such as Rust/Scala/Haskell pay substantial dividends, but there is the 'socio-' aspect of the context for you!
In Go it is already visible with developers using error handling libraries and code generators.
I agree with this. It is a ~zero-sum game. We note this phenomena in terms of concurrency, system architecture (microservices), as well: deceptive up-front simplicity will exact recurring payments with compound interest :)
Frankly I think this says far more about our [field] (academic to industry) than any specific tool, or language.
We have a problem in this field and we haven't solved it. (My money is on machines writing most of the code in the future.)
> In Go it is already visible with developers using error handling libraries and code generators.
Agreed, but note that while I'm critical of the uncritical embrace of "solutions" that don't spell out the consequences on the proverbial tin (such as microservices), at least they get to float their boat. Consider that lacking this alternative a possibly substantial subset would be sitting on the beach dreaming of sailing :)