The point is that by keeping generics out of the language, Go designers have forced the developers to look out for solutions of their own.

Which funny enough, happen to be similar to the ones in use before generics were widely available in the mainstream.

Fair enough--I'm just saying I actually wouldn't mind if the actual eventual solution in Go were a bit gotgo-like (though I'd like it to be standard, not require an extra build step, etc.). Making adaptable containers without extending the type system might even be the Go-y way to do it, though it probably wouldn't win many converts from other languages.

(Or, from the other end entirely, I could see polymorphic functions happening--they'd complicate the Go compilers more than macro-like generics would, but using them would feel familiar for Go's many refugees from duck-typed dynamic langs.)

Anyhow, I'm fairly aimlessly spec'latin' here, don't listen too much to me.