I'm fine with Go having a handful of built-in generic containers+functions. In fact, I think most people asking for "generics" would have their true needs met by adding a few more built-ins to the language. I pursued that idea here: https://github.com/lukechampine/ply

I sympathize with the programmers who really do need generics and would like to program in Go, because I love the language. But the way I see it, 95%+ of programs don't truly need generics. I like the trade-off Go makes by omitting generics, and it makes me sad that the language could change in such a radical way to meet the needs of that <5%. A language doesn't need to be perfect (or even usable) for everyone! Throwing in feature after feature to satisfy everyone just creates a culture of compromise and destroys a language's character. I want a set of narrow tools that I can master. No one ever complained that a hammer makes a terrible paintbrush. So in a broader sense I think this whole discussion reflects a wider need for good languages. We need ten languages of Go's caliber! I know the "just use a different language" argument is kinda callous, but the alternative feels worse.

I don't have any opinions on adding generics to Go because I don't have a sense of how it interacts w/ other features of the language, but having to specialize all your types to specific uses means there are very common types of libraries that are significantly harder to find in Go than in other languages, or are much less useful, or work around the lack of generics w/ interface{} casts and are significantly less type safe. I suspect that people who deny the value of generics enjoy learning about the implementation of these things and writing them themselves rather than using libraries. Don't get me wrong, there's value in that, but it's at the expense of writing libraries with stable interfaces, boilerplate-free code, large systems that can easily be refactored, etc.

It also makes it harder to actually use a type system for the value it provides: the ability to encode facts about data irregardless of their provenance. Libraries may provide interfaces that work on a certain number of presumed useful primitive types, but your own types can encode far more constraints. Without the ability to use those types you will have to care about provenance again (has this value been validated for use by this function?) or constantly reuse a normalization process to construct those values, which may introduce conversion overhead and creates more error-prone situations. Not to mention that generics also provide constraints about what a piece of code _cannot_ do. The example made famous by haskell programmers is that an "fmap" function defined as such cannot tamper with the values being mapped over, since it has no knowledge of their concrete implementation:

fmap :: Functor f => (a -> b) -> f a -> f b

Genuinely, I don't understand why you would create a static type system in a new language that didn't allow for parametric polymorphism, it's one of the most fundamentally useful features in type-checking code.

Yes, they do. Pretty much 100% of programmers in statically-typed language need to use generic types/functions.

The "95%+" thing is just an observation that one typically needs to define type-parametrized structures of function very seldom. This is true, but it's in no way a good point against adding generics, because those remaining ~5% of cases are crucial for peaceful programming the other ~95% of times. That's why Go has built-in generic types, but as it's adoption grows, it's becomming clear they won't do any more...

> In fact, I think most people asking for "generics" would have their true needs met by adding a few more built-ins to the language.

You argued against magic and now you'd like to add some more of it to the language...

Only snag, minor enough, is that emacs auto-indent becomes confused by the double braces, as in "{{.templateVar}}".