[thanatos_dem]

How often do you find yourself writing or using `interface{}`? It’s littered all over the go code I’ve seen, including the standard library.

`interface{}` is the equivalent to using `Object` in java land. It completely punts on any sort of type safety, relying on the developer to handle messy edge cases correctly. I think one of the only reasons that it hasn’t been as severe a problem in go as java is thanks to that explicit error checking that go makes developers do (and that gets so much hate online), forcing developers to consider the case that the type isn’t what they assume.

But genetics provide a useful way to safely make those assumptions, and cut down on the boilerplate around them.

[majewsky]

> It’s littered all over the go code I’ve seen, including the standard library.

From my experience, interface{} is incredibly uncommon in application code. In most instances where the standard library uses it, it's usually justified because the function in question really accepts literally any type of argument, e.g. json.Marshal() or reflect.TypeOf(). The only counterexample I can think of are sort.Sort() and sort.Slice().

Given all the implications of adding generics to the language, I think Go would be better off just adding the common higher-order list/map manipulation functions to the builtins, i.e. the likes of map(), filter(), maybe reduce().

[asdvxgxasjab]

I use it all the time indirectly when using a map or working with JSON. I don't find it all that messy to work with. If you're talking about type assertions, I don't use them all that much but they do come up. It doesn't require much boilerplate or special handling. If the assertion fails I return an error like I do everywhere else.