Which is why most simple languages created as a reaction to complexity, end up with complex codebases full of workarounds to fill the lack of features.
In Go it is already visible with developers using error handling libraries and code generators.
> Which is why most simple languages created as a reaction to complexity, end up with complex codebases full of workarounds to fill the lack of features.
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 :)
In Go it is already visible with developers using error handling libraries and code generators.