Thanks
The key is that an `interface{}` is an interface with exactly 0 methods. Since all types in Go have at least 0 methods, any type satisfies `interface{}`. Resorting to using an `interface{}` type is akin to dynamic typing. All of your type errors get pushed to runtime and you lose any performance benefits you might get from the compiler knowing the type of your data.
Russ Cox goes into great detail on the representation of interface values.[1]
I wrote a blog post a while back on conveniently writing parametric functions in Go using reflection.[2] (Here, "convenience" is a relative term.)
[1] - http://research.swtch.com/interfaces
[2] - http://blog.burntsushi.net/type-parametric-functions-golang
I hope not! It was purely an experiment. There are significant draw backs, particularly with respect to performance.
One could reasonably argue that writing parametric functions with reflection should be hard, so as to discourage users from resorting to it too easily.
> What do you think about Go designers being generally averse to the idea of parametric polymorphism?
I think the jury is still out. Russ Cox laid out the essential trade offs given to them: 1) slow programmers 2) slow programs or 3) slow compiler. There's a lot of wiggle room in there (what do you mean by "slow"?), but my sense is that they're still looking for a trade off they're happy with.
In my experience with the Go community, there isn't a ton of internal complaining about the lack of generics. It's certainly brought up now and then, but it doesn't seem to put people off too much. Now, obviously this could just be confirmation bias, but if the Go community keeps growing despite the lack of generics, it may be difficult to justify generics in the future. (i.e., People will live with the first trade off.)