[edenlinger]

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. If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language.

I am probably an old man yelling at clouds and I hope those who like this style get tons of value from it. I just don't see the benefit of trying to retrofit some of the behavior of other perfectly useful languages into Go. JS/Java/C#/Python/Ruby is a fine language. Let each of them have their strengths. I feel like trying to bolt things together this way only serves to take away what is special and valuable in Go.

I should probably shut up and just be happy lots of other people are using a language I enjoy :)

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

[honkycat]

> If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language.

Generics were widely asked for by the community for many reasons, one of the main things being reducing boilerplate and having basic polymorphic functionality that other languages provide.

I'm not trying to disparage you but: You don't know who I am, or my capabilities. Please don't be condescending to me and assume I just "don't get it" or that I am too lazy to learn the "go" way of doing things.

I am seeing that a lot in this comment section. You are judging others and coming to conclusions because we like something you do not like. I can totally understand your perspective, because I also see the danger of introducing more "power" into a language that was elegant and simple.

I respect your disagreement with introducing generics to Golang. However, please extend us the courtesy of assuming we are at least remotely competent.

[edenlinger]

Man, I totally missed the mark if this is how you interpretted my comment. I never meant to imply any competence level. Certainly didn't meant to direct any judgment at you. Simply trying express the issue I had with the lo package.

I'm really happy we have gotten generics. I think some of our lower level tooling will be much easier to build. I know lots of the community will likely be happy to have non reflect based ORMs come out of that work. I have a coworker who has expressed interest in building a new json:api parsing library with generics. Happy we have it.

The map/reduce/filter and some of the other _ style helper functions from lo was what I was trying to speak to. Those idioms just don't seem to fit well in the language. The clarity of the single way to do something in Go has been immensely refreshing. I appreciate that so often Go code looks like Go code. I also don't find myself pondering which iterator to use or chain together to accomplish something. I just quickly go to a for loop and move on. In Ruby/Java/JS/Python I often find myself deciding which chainable to use instead of just solving the problem and moving on. The language is certainly not without its warts or shortcomings. To me it feels like if those kinds of options are things you really enjoy using in a language, it would feel more natural to use a different tool. Sacrificing that clarity seems to remove some of the biggest reasons to use the language as opposed to something with fewer limitations.

Sorry if I came across as condescending. Not a stereotype of the community I intended on perpetuating.

[int_19h]

It's worth remembering that Java and C# didn't have generics initially. And when they did get them, there was a lot of pushback along the same lines; sometimes almost word-to-word about lost simplicity etc.

18 years later, the C# and Java developers are doing fine.

[pjmlp]

It's worth remembering that C# did have them pre-release, Microsoft decided to release .NET 1.0 without them to avoid postponing the release date until they were fully done.

This is clearly described in the HOPL papers regarding generics in .NET.