I find generics are overused in most languages. Go will be getting generics to handle the very few situations in which they are a genuine value. But the most common uses cases for generics in other langues are already handled by Go interfaces.
For example Go's `sort.Interface` provides a mechanism to implement generic sort, find and set operations on any type of collection that implements those three methods (Len, Swap, and Less).
I nearly never find myself having to use `interface{}` in my Go code, and those that do usually don't have to, they just don't want to define an appropriate interface.
I recommend https://golangnews.com/ too, Not just because of its utility or that it has HN interface but also because Kenny Grant has been contributing to the Go ecosystem for a long time and his code is a pleasure to read.
There is nothing wrong with a well documented interface. The `is-a` pattern and `has-a` pattern are all I have ever needed when composing "objects" in golang.
Usually, the `interface{}` is named something like `Xer` to denote an interface which satisfies `X`. So - `Dialer` would be the interface and any struct is free to implement the `Dialer` methods to qualify as one (for example). Presumably requiring some way to `Dial` something.
What I like most about `go` is how standard a lot of the "good practices" are, with a focus on getting stuff implemented. There is no time to argue about spacing and bracing, just run `go fmt`.
I dread the appearance of generics. It's not just that they lead to longer compile times for very little benefit, it's that everybody wants every thing to be generic, just in case. Like the C++ dogmas around how many of which type of constructor you need, generics encourage fast-spreading, deleterious memes.
