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

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

I just wanted to make some small functions for logging different types of things. I wanted to use parametric polymorphism to dispatch to different functions depending on the type of the thing I passed in. I think I ended up creating a few `log_type_foo` and `log_type_bar` functions rather than the single `log` function I wanted. It looked really ugly to my eye.

The thing I really wanted was parametric polymorphism. I seem to remember reading something where the go people think this is equivalent to generics.

EDIT: clarity

  func DoWorkWith(foo Loggable) { ... }

  type Loggable interface {
    //for example
    LogTo(os.Writer)
  }