http://golang.org/doc/faq http://golang.org/doc/faq : "Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't

http://golang.org/doc/faq http://golang.org/doc/faq : "Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly." One of Go's goals is a certain level of simplicity. The above point seems to state that generics don't fit that goal, but they are not precluded from a future version. I take this to mean that since no language has every feature that anyone could possibly want, if generics are a requirement for your work, then Go does not fit the requirements. Some potentially relevant material here - http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.de/2012/06/less-is-exponential... : "Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark."