[jerf]

"Nobody" uses this stuff in Go. I mean I'm sure it's not literally nobody, but I'm yet to encounter even one example of someone using this stuff in the wild.

I'd love to be able to survey the authors of the dozen-ish variations on this posted over the last couple of years (most of the much less elaborate than this) and see how many of them are still using it in their real code. Again I'm sure the answer isn't literally zero but I bet it's statistically-significantly fewer than all of them.

[cle]

Saying no to generics sends a strong signal to FP astronauts to "take it somewhere else". This saying no to a huge number of things is the superpower of Go and its community IMO, but those "go away" signals are getting weaker over time, which increases the likelihood of needing conversations and decisions about when to use what style, which is exactly the sort of thing I enjoy not having to do with Go.

For example: this entire HN thread. And all the other libraries you mention that keep soliciting conversations, nerd sniping people who could be spending that time making better products instead of quibbling over FP code golf. But maybe those folks will always find things to quibble over...

[jerf]

The primary "conversations" that are spawned almost entirely consist of 1. people saying no thank you and 2. people expressing concern that this will become successful.

You can stop worrying about generics causing this.

Iterators may do a bit, but I still think that based on what is currently baking that people are going to find trying to do large amounts of work through iterators is not going to scratch their itch to do everything in a foreign paradigm.

If you want to work in a certain paradigm, then for pete's sake, do it. Go do it in a language where it's the best solution. Don't find the best solution in X, then try to jam it into Y at all costs. This isn't special to X = Haskell and Y = Go, it's true for all combinations of languages.