[kortex]

> I don't mean to disparage the wonderful work of the lo developers but, > this is in many ways what I feared generics would bring.

What is, anything in particular about that "lo" library? Just the way it uses generics, or moreso that it's yet another library to learn to be effective? Can't argue with the latter, but as far as the former goes, I think that looks quite reasonable. It's very explicit, there's no magic going on. I think there's definitely a bar for "so much abstraction that it is discouraging to developers not into that sort of thing", and IMHO that doesn't cross it. Monads, sure, that's a tall order for many folks. But this is pretty tame.

But I am a fan of abstraction so I'm not the best judge.

[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.