I used to miss generics in Go, but after a few years of coding in both Go and Java I recognize the costs, but also the benefits of their absence. We use generi

I used to miss generics in Go, but after a few years of coding in both Go and Java I recognize the costs, but also the benefits of their absence. We use generics to define new abstractions. This allows us to reduce redundancy in code and provide succinct way of expressing complex concepts. The main cost of not having them is that we have to fully write out the algorithm more often. At some point I realized that when I read someone else's Java code I often find myself digging through countless layers of abstraction, factories, builders, suppliers, visitors, delegates and each each time I have this thought in my mind: "so where the hell is this place where the stuff actually happens?" In Go, this place is right there inline in front of you or very few hops away. This is particularly important if you're trying to understand a corner case, e.g. how does this function/class behave when I give it an empty list or null. Faced with the choice between having to understand an abstraction or an algorithm I prefer an algorithm. Most mainstream languages have generics. I'm happy there is one that does not. (Disclaimer: I am by no means a Go apologist: I have very mixed feelings about the language overall. One thing I was hoping would be discussed in the article was that channels don't compose well with other concurrency primitives, e.g. one cannot select on a channel and a condition variable) EDIT: formatting