I don't believe anyone from the Go team has said that using interface{} in containers is "the "correct" way to build generic data structures". It is merely one

I don't believe anyone from the Go team has said that using interface{} in containers is "the "correct" way to build generic data structures". It is merely one of the ways available today. (The other is to define algorithms in terms of operations, like sort.Sort does with sort.Interface.) We're not saying either of those are "correct" in the sense of optimal, but they're what we have now. Robert addressed generics in his talk (summary at https://sourcegraph.com/blog/live/gophercon2015/123645585015; https://sourcegraph.com/blog/live/gophercon2015/123645585015... I believe the video will be available in two weeks). Quoting the sourcegraph summary: > Generics is the single biggest language feature absent in Go. It’s often missed by newcomers to Go. But it’s more of a type-system mechanism. It’s unclear if it’s an essential language feature. > Generics are incredibly complex in both semantics and implementation. There are considerable trade-offs to consider, such as do you want a larger binary vs. slower binary vs. larger source code. > It’s also very non-orthogonal. It interacts with and complicates a lot of other language features. > They have tried and implemented prototypes of generics in Go, but they haven’t found a good solution, so they’ve decided to hold off and keep thinking about it for the time being. Robert also made the point that generics are very complex, much more so than most people realize. See also https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417.