The author said that he needed a generic set for different concrete types, so he'd have to write a bunch of these functions for all the combinations he needed. And he did. And it was a mess. And it was also slow.
Edit: not that we can conclude anything from the lack of performance, though, we don't know how it was written.
My guess would be too much "noun oriented thinking".
Some of us came of age before the tyranny of King Java, learning such obsolescent tools as Pascal, Lisp and C back in school. (I'm gonna ignore BASIC and FORTRAN, other than as examples of what not to do) We learned how to pass around individual functions/procedures to support library code.
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.
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.
If you allow some helper functions or an interface to do things such as compare/hash members, it's totally doable. Extra points for passing the helper(s) into the constructor.
Yes, you can still mismatch set types, but the casting/type-assertion in the helpers will fail with an explicit reason.
Almost forgot: in Go, classes aren't "closed". While you cannot "monkey patch" and change existing methods, you can define new functions, such as my_set_comparator, that accept each given type as "this". You would then make a new interface, such as my_set_element, which defines method my_set_comparator, and any data types for which you had defined my_set_comparator would automagically meet the new interface.
