> First, many (I dare say most) Go developers[0] don't really use any "solution" for this other than the features built into the language itself. In other words

> First, many (I dare say most) Go developers[0] don't really use any "solution" for this other than the features built into the language itself. In other words, they're not out there writing alternative solutions because they genuinely don't perceive a lack of generics to be as big of a problem as other things, which they do write tools for. I dare say that most people don't use generics, because most people are not library authors and abstraction builders. As soon as you get into that territory, the lack of generics starts to seriously hurt. Because it's one thing to build a component that's very specific to a job at hand, it's quite another to build something reusable and I'm not even thinking about reusability by other people. One example would be data-structures. Sure you can build your own concurrent data-structure for moving bytes between threads, sprinkled with domain specific utilities that operates on it, because that's what your application requires. It's quite another job entirely to come up with a set of reusable data-structures that can be used no matter the contained values and that exposes high-level operators for manipulating them and then you end up building half-baked data-structures for each job at hand you have. Another example is abstracting over common patterns by means of higher-order functions. Say you want to send messages between channels, threads, address spaces or what have you, in classic producer/consumer style, but without the producer carrying about whom subscribes to its notifications. Then you realize that your stream could be manipulated for fetching just the information that you want by means of `map`, `filter` or `flatMap`. Say you want to abstract away the loops one normally does with the atomic CompareAndSwap, so you think of operators like `transformAndGet(f: OldValue => NewValue)` / `getAndTransform` and `getAndExtract(f: OldValue => (Extracted, NewValue))`, which are not uncommon in other languages, so it's not like we are being original here. Basically, every piece of abstraction that could happen with higher-order functions is overkill for a static language without generics in it. And people don't see it, because most people aren't thinking of doing abstractions by means of higher-order functions. And Go's interfaces are seriously not enough because we are talking about a different kind of polymorphism here. And in regards to people coming up with their own solutions, I see it no different than with Perl and the lack of OOP-ish facilities baked in the language that drove people to building multiple, often shitty and incompatible alternatives. Yes, this eventually led to Moose, but the ecosystem is still plagued by older implementations, because open-source never really dies. And I would remind you that most people that were using Perl in the beginning had no use for OOP, it just so happens that people eventually did need the libraries that needed OOP, going back to my original point that it doesn't matter if most people don't feel a need for generics, the more important question being what do library authors think about it and I'm pretty sure that people publishing libraries aren't happy.