So, are you saying that it's impossible to declare a function without generics? How did the world run before generics were invented?
We used code-generators or pre-compiler macros or dynamically typed languages or we hand-wrote heaps upon heaps of boilerplate.
It sucked.
And regardless, Go only offers the last option.
Edit: not that we can conclude anything from the lack of performance, though, we don't know how it was written.
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.
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
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.
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!)
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.
new_set = old_set.union( another_set, element_comparator_func);
Yes, you can still mismatch set types, but the casting/type-assertion in the helpers will fail with an explicit reason.