[morelisp]

Efficient map/filter/reduce chaining basically requires JIT to fuse the operations and/or a GC prepared to deal with huge amounts garbage. In Go, filter(h, map(g, filter(f, a))) will be immensely slower than the equivalent for loop.

[kortex]

Great point. Although, that sounds like a typical example of "let's write it the ergonomic but less performant way first, then profile and refactor as needed". That seems very tractable for that sort of refactor, especially with type safety.

Also I would not be surprised to see JIT-like behavior from go tooling, first party or otherwise, if that sort of approach takes off.

[lifty]

And now we introduced 2 new problems: 1. We have 2 ways of doing stuff (boring loop vs map) 2. We have a new hidden way to introduce performance degradation by importing a library that uses map

You might argue that you should know what you're importing, but in practice, it can hurt the overall ecosystem. I'm still supporting the introduction of generics, but the tradeoff should be clear to everyone.