They seem more complex compared to a type parameter when you are only thinking about this narrow situation. However, generics are not limited to this narrow situation and will cause complexity far beyond what you are imagining.

Having said that, I honestly don’t know if generics are a net positive or not. What I can say is that go is one of the few languages where I can jump into an arbitrary go code base and make sense of it relatively easily. Risking that is a scary proposition for me.

I'm well aware when they are useful, I've been using them in languages for the past 10 years. By the same token though, leaving type parameters out of the language has had far reaching implications outside of this "narrow" situation (I'll put forth that implementing a data structure isn't a narrow situation). Error handling and the lack of sum types also seem particularly egregious and are heavily influenced by the lack of generic types.

> Having said that, I honestly don’t know if generics are a net positive or not. What I can say is that go is one of the few languages where I can jump into an arbitrary go code base and make sense of it relatively easily. Risking that is a scary proposition for me.

I don't see how type params would make this harder, I daresay I can think of a lot of instances it's much easier. The caveat is that you simply don't understand them, in which case it's a good thing to learn as many languages do have them.

In any case all these arguments are well trodden so I'm probably wasting my breath re-hashing here.

I’ve been using them for the past 30 years and have come to a different conclusion. You have plenty of languages that do what you want. I hope go doesn’t lose what made it different

Oh sorry, you were saying lack of generics were the reason you could make sense of code easily, implying that if a language has generics you can't make sense of it. That seems juxtaposed to having used them for decades. In any case I can tell you're passionate about this so I think we can just agree to disagree.

That said I don't think there's much "hope", from the looks of things it is coming to Go.

I'm hoping that Go still keeps it's relative simplicity. It's lack of inheritance gives me hope that generics won't be as complicate as it is in other languages.

I understand generics well, I just find code bases that use a lot of abstractions harder to read than Go.

You know? Original Java was a fairly simple language :) Generics were added in 2004 in J2SE 5.0.

Just call it parameterisation, it's less scary then. The unknown is always scary but having the ability to parameterise - including types - is well traveled ground.

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.

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.

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.

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?

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

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 :)

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)