[xelamonster]

I agree, but I also appreciate this because missing map/filter/reduce is probably my biggest pain point when writing Go. Nested for loops and explicit filters are so ugly and hard to read, for me that alone undoes any of the appeal of the language's "simplicity".

[ljm]

I'm only partly convinced that bringing functional abstractions to various kinds of collections/iterators/enumerators, etc. adds value to Go, both in terms of reading code and writing it. That's pretty much as far as 'functional programming' goes when this topic comes up.

It brings Java libraries like vavr to mind. The concept has appeal if you appreciate the aesthetics of functional programming but your codebase will be filled with places where you have to convert between the sexy functional style and the boring shit in order to get anything done.

It's better to just roll with the language and stick to where it excels. It may not be as easy on the eyes and it may also be boring to write, but a lot less can go wrong with it.