>Generics would be really nice for generic data structures (heaps, trees, etc), but code generation is ok at that. Either code generation is an implementation

>Generics would be really nice for generic data structures (heaps, trees, etc), but code generation is ok at that. Either code generation is an implementation detail of generics, or this is an afterthought that adds incidental complexity and was almost assuredly better off being a core language feature. >I think it's hard to quantify the massive benefit Go's simplicity is to onboarding developers This is really only applicable to small applications using new languages where the main cognitive onboarding is learning a new language/paradigm. As soon as you reach a certain size of application, the frameworks, architecture and domain knowledge heavily outweigh the cost of learning even the most esoteric of language features. >Any language features which increase cognitive overhead had better offer some extremely compelling benefits to outweigh an increased learning curve I wonder what kind of language feature you're talking about? The whole idea of generics in a more functional oriented language is to reduce cognitive overhead. The beauty of parametricity is it takes things away from the developer to help them reason about the code! Our (very large) team of engineers use this to great affect throughout our codebases. There is no such thing as a silver bullet, but this comes as close as I've seen in the 12 years I've been an engineer (from startups to a Fortune 10 company).