[nf]

No, that is not what I was referring to. It is definitely user code complexity that turns us away from generics.

People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.

[mercurial]

As somebody using pre-generics Java libraries from time to time, I can say with confidence that generics are not the cause of complexity. Casting from Object is a source of bad type safety and doesn't help with documentation. The complexity you'll find in a mature codebase is a function of the way it is architectured and the complexity inherent to the domain, mostly.

[NateDad]

I wish people wouldn't assume there's only two options - Generics or casting from Object/interface{}/void* It's a straw man argument. No experienced Go programmers are trying to say that's a good way to write code. The idea is to restructure your code so that basic data structures and interfaces pick up the majority of your reuse scenarios.

[mercurial]

I'm no Go programmers, but I relatively often need to take a parametrized basic data structure as storage and write a parametrize class on top of it, while hiding the data structure because it's irrelevant.

Well, I guess I'll keep not being a Go programmer :)

[spion]

I'd say people tie themselves in inheritance and interface knots more often than generics knots. Especially invariant generics are rather hard to get wrong - they place such constraints on the types that most operations are unavailable.

[the_af]

> People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.

That's not my experience at all. Generics are generally not a source of pain. Do you have any specific examples of your claim?

[tomp]

People tie themselves in knots with classes/packages/interfaces/concurrency/computer code all the time. Just look at pretty much any mature codebase at all.