[Firstmate]

New to Go still, what kind of caution should one take when using interface{} to store data in structs? It seems to be a catch-all sort of type, I've read how cluttered some code can get when using it (I think it was an HN post related to math in Go, and type-checking against an interface{} type).

Thanks

[burntsushi]

A general rule of thumb: don't use `interface{}` unless you have to. With respect to performance, it isn't free. And with respect to type safety, it isn't safe. (It is however memory safe when casting, unlike C's `void *`.)

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

[tuxcanfly]

Is there a chance ty or a similar implementation will make it into Go core? What do you think about Go designers being generally averse to the idea of parametric polymorphism?

[burntsushi]

> Is there a chance ty or a similar implementation will make it into Go core?

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.)

[NateDad]

My expectation is that they'll end up giving us something that'll make it easier to work around the lack of generics, but I don't know about getting actually full-on generics. Honestly, I don't want them - they make it way too easy to make overly complex code.... much like class inheritance. I've been developing for 14 years and can count on one hand the number of times I needed something like a tree or graph. Certainly, if you're working on scientific or mathematic projects, you may use them every day of the week, but if so, maybe Go isn't the right language for you, and honestly, it doesn't have to be everything to everyone.

[burntsushi]

I'm skeptical that trees and graphs are the only thing generics are good for, but, I've published research with open source software written in Go.[1] I've also done it for Haskell.[2] I just try not to pigeonhole languages and learn as much as I can about different paradigms. In my experience, they all have something useful to offer beyond trees and graphs.

[1] - https://github.com/BurntSushi/cablastp

[2] - https://github.com/ndaniels/mrfy