Generics actually have very little to do with sorting a list in Go. The example that the parent gave could be expressed in one line as "sort.Sort(sort.Reverse(sort.StringSlice(vs)));" No generics needed-- only composition. sort.Reverse is a wrapper interface which can be composed with any other sort.Interface to reverse it. It is typesafe, too-- there are no typecasts.
There are cases where generics would allow us to avoid typecasts, but this is simply not one of them. In many cases, what you want can be expressed via composition of types, and often (in my opinion) in a clearer way than by using lambdas, continuations, and callbacks. I suggest learning a bit more about the language and keeping an open mind.
If you say so -- I'm just going off of the examples given in the Go documentation on how to sort lists. If that's not the "Go-ic" way to do it, perhaps the documentation should be updated. If it is the "Go-ic" way to do it, then I think that my point still holds.
I also don't really have a lot of excitement about the prospect of solving problems by composing types in Go. For instance, to the best of my knowledge, Go does not have language support for sum types. It's not that I'd rather use continuations or callbacks -- I like powerful, expressive type systems to do, e.g., static enforcement of contracts -- it's just that I think that Go's type system isn't very expressive.
You're right, perhaps I'm totally misinformed about the language, and that lurking below there really is a way to do clear and clean things with types in Go. But everything I've seen points in the opposite direction, so at this point, though I have an open mind, I'd need more evidence to change my view.
The example we were discussing was written by Mark McGranaghan, and is not part of the go documentation per se. I think it's a nice little tutorial, but please don't confuse it with "the Go documentation."
Mark's point was that you can create an arbitrary wrapper type around another interface, so that the behaviors are composed. This is the most flexible way to do things. If there's already a wrapper type that does what you want, however, then you can simply use that. They are both examples of composition, and both "the Go-ic way to do it."
Composition is often overlooked by people who are fixated on other ways of doing things, like inheritance or generics. But in many ways, it's cleaner, since composition allows you to link together many modules without peeking inside.
It's funny that people have accepted the reality of dynamic languages, but can't seem to "get" the idea of statically typed language without generics. There isn't a troll comment in every Python article that it would be better with static typing. Type systems are a little bit like body armor-- development can be slower, but in exchanged you get a little more confidence in the program. People have accepted the idea of going naked, and the idea of medieval-style full plate armor, but the idea that you might want some type safety, but not go overboard often seems to fall on deaf ears.
Actually, the example I was referring to (see my comment elsewhere in the thread) is copied directly from the Go documentation here: http://golang.org/pkg/sort/
Composition is great. It does not solve the same problem as generics. The reason people can't seem to "get" the idea of statically typed languages without generics is because static typing without parametric polymorphism is a painful experience.
I'm not opposed to the idea of finding some balance between static and dynamic typing -- Clojure type annotations seem interesting -- it's just that I don't like the way Go does it.
Generics actually have very little to do with sorting a list in Go. The example that the parent gave could be expressed in one line as "sort.Sort(sort.Reverse(sort.StringSlice(vs)));" No generics needed-- only composition. sort.Reverse is a wrapper interface which can be composed with any other sort.Interface to reverse it. It is typesafe, too-- there are no typecasts.
There are cases where generics would allow us to avoid typecasts, but this is simply not one of them. In many cases, what you want can be expressed via composition of types, and often (in my opinion) in a clearer way than by using lambdas, continuations, and callbacks. I suggest learning a bit more about the language and keeping an open mind.