[zelphirkalt]

Go was created with simplicity of feature set in mind, which does not translate into developer ergonomics automatically. It rather offers a least common denominator of lang features, so that most devs can handle it, who previously only handled other languages like Java and similar. This way Google aimed at attracting those devs. They'd not have to learn much to make the switch.

True developer ergonomics, as far as a programming language itself goes, stems from language features, which make goals easy to accomplish in little amount of code, in a readable way, using well crafted concepts of the language. Having to go to lengths, because your lang does not support programming language features (like generics in Go for a long time) is not developer ergonomics.

There is the aspect tooling for a language of course, but that has not necessarily to do with programmming language design. Same goes for standard library.

[eudoxus]

Rob Pike quantifies your sentiment as "Orthogonal Features"[0][1], which isn't necessarily equivalent to "simplicity of feature set". But I do understand what you meant.

I think in this context tho, developer ergonomics can mean different things to different people.

It's easy to see how "Orthogonal Features" can be interpreted as developer ergonomics, as its explicitly limiting potential (not all) anti-patterns and produces fairly idiomatic code across the ecosystem. I'm able to go to almost any Github repo that contains Go code, and easily determine whats going on, whats the flow, etc. Certainly ergonomic in that context.

[0]: https://go.dev/talks/2010/ExpressivenessOfGo-2010.pdf

[1]: https://www.informit.com/articles/article.aspx?p=1623555