[int_19h]

It is exactly the same kind of polymorphism that languages like Java and C# had before they adopted generics. In practice, what this means is that you have downcasts all over the place, which is tedious, non-typesafe, and is why both C# and Java have generics now.

The fact is that Go is the only statically typed language, with any claim to being mainstream, that doesn't have generics. And it's not like generics are some kind of a new and radical concept. Java had them for 13 years now; C# had them for 12. There's literally millions of lines of code written in popular languages that utilize generics, which can be used as a guide to proper design, and understand its consequences.

The idea that there needs to be more "baking time" for generics simply doesn't hold water at this point. It amounts to insisting that structured programming (loops etc) should not be adopted "without fully understanding the consequences at all levels", and meanwhile we'll just use if+goto - in 1980.

[grahn]

If you want to understand the reasonings the Go maintainers have about generics, there is a GitHub issue[1] on it that is probably a better place to start than to argue with me. The thread references both recent academic research as well as other programming languages' take on the subject.

I don't think their crux is so much that generics "as such" needs more baking, but the specifics of how to implement them with the Go language. Mind you that some of the core goals of Go is to be simple, easy to parse, fast to compile, support good tooling, etc. so the question they're battling with is how to add generics to that mix without sacrificing any of those goals, and without making some mistake you can never go back from once every code base out there starts depending on it.

Now, by all means, we can argue that those priorities are wrong, or that yours would have been different. But I think it is disingenuous to suggest that they are effectively idiots who don't understand how to apply basic concepts, or are unaware of other programming languages.

[1] https://github.com/golang/go/issues/15292

[int_19h]

No-one is suggesting that they're idiots, though. The original argument is that Go designers are very conservative, and extremely averse to some language features that aren't even "new" anymore - not that they're unaware of those features or how they work.

[burntsushi]

> It is exactly the same kind of polymorphism that languages like Java and C# had before they adopted generics.

That's false. Go provides a smattering of blessed polymorphic types (slices, maps, chans, pointers) and functions (len, append, delete, chan send, chan recv) that go a long way. They are horrifying to civilized PL enthusiasts, but they cover a lot ground.

As I said in one of my sibling comments, navel gazing isn't going to get you anywhere. And Go isn't the only statically typed language without generics. C has that designation as well.

[int_19h]

C is one of those things that hasn't meaningfully changed in decades now. So yes, technically it is a mainstream language without generics (and many other things) - but I don't think that's a viable role model. The only reason why C is what it is, is because of all the legacy code written in it.

[burntsushi]

Who said anything about C being a role model? I think your chosen language is somewhat misleading, so it's worth pointing out.