Well, as we all know, Go does give you a way, sort of. You'd have to write basically a dynamic version using interface {}, and then write wrappers casting the values in and out, and possibly handing out the equality predicate.

That sucked in Java at the time, though, when you had to screw around casting Objects in your code, I don't see why people would prefer that.

Surprisingly, Erik Meijer (Haskell, C#) can somewhat see the appeal of no generics and a bit of casting:

22m-31m http://www.youtube.com/watch?v=on5DeUyWDqI#t=22m

(I give myself and Google a pat on the back for being able to remember and quickly find this!)

Thanks.

For the app being described, would there really be six different type signatures required?

Generics would absolutely be nice for Go, primarily because they would allow the core libraries to provide all of these rich collections. However if we're discussing the notion that someone can write these themselves, it just seems contrived that people think generics are critical for any specific app -- in the example he described, it sounds like he would need one single concrete implementation.