[Fire-Dragon-DoL]

This can be said for any programming language and any community: there will always be bad code written by someone.

Generic data structures are provided in many programming languages and there are many people that are very experienced in writing some of these, so being able to reuse, it's precious.

In general the lack of generic price surfaces when you write libraries, not applicative code. But libraries are a big portion of a codebase.

[jshen]

I’ve been coding for decades. I’ve used all the fancy functional languages, written production code at scale with complex type systems, etc. my experience, they don’t add a lot of value compared to the costs. In my old age I’ve grown to prefer go for it’s simplicity. I hope we don’t lose it, and you all have the option of using the myriad languages that already do what you are looking for.

[Fire-Dragon-DoL]

I think you misunderstood my point (maybe): I totally agree with you. I've been coding for many years and coming from Ruby where you can do "the worst stuff you can think off" (really bad stuff: monkey patching, building DSL etc.), I came to Go exactly to get relief from all of that. I don't trust people having their hands on all that power.

Still in my short Go career, I worked on at least 4 libraries, one of those needed generics to gain a huge performance boost, the other worked around the lack of generics, but I still wish it had it (a special kind of logger). In applicative code, the main issue with lacking of generics is the lack of generic slices functions (map/select). Initially I thought it would be fine, but then I wrote a piece of code that was visibly involved in copying data from one slice to another with some changes and that "shadowed" the "central" part of the code behind a bunch of loop codes. In those cases, to improve the ability to easily scan through the code, I wish I had some generic slice function to deal with it. I appreciate doing loops, but sometimes they are verbose enough to hide the interesting part of a piece of code. This is especially visible in applicative code where usually performance is not as important as much as the business logic.

[brundolf]

Go has some "special" built in functions like len() that work across different structures. What if instead of adding generics they added more of those special functions for working with slices as you describe? Would that have solved your problem?

[Fire-Dragon-DoL]

Of course, but remember that `len` has constant return type, while in case of slices you'd have a return type that's different on the input slice

[brundolf]

I see. I guess I assumed that the category of special "privileged functions" would have their powers extend to cover stuff like that (I haven't used Go, I'm just going off of what I've read)

I'm very intrigued by the no-generics idea, so I'm prodding at what might've made it workable enough that this reversal wouldn't be necessary :)

[Fire-Dragon-DoL]

All good!

Well in Go the assumption is that you jump to interface{} (equivalent to Object in Java or void* in C) when you start having these kind of problems, but there is a performance penalty in doing that, which shouldn't be there if generics are present (and makes the code DRAMMATICALLY worse with all the casting)