[omegabravo]

It's a shame that this generics debate is framed as a "go programmers discover generics".

That has never been the source of contention, and the benefits were noted from the initial discussions of the language before it reached an audience. Like all things it's a trade off. Will you be providing more value with generics, or are other features a higher priority. That's obviously a matter of perspective.

Go has many advantages over other languages, and strict typing, generics and raw speed has never been part of that. If those things are paramount for you, there are better languages suitable.

Go has been fantastic for the problem space I'm targeting. Fast enough, efficient enough, portable enough, simple enough that hiring is easy. This might not be true for what you work on, but I'm not writing a video decoder.

[threeseed]

> go programmers discover generics

It kind of was though.

It was endless arguments from Go users that generics aren't needed and can be solved through a combination of cut/paste, code generation or simply dismissing its usefulness altogether. And on the other side the rest of us trying to explain the many, many use cases that demand generics.

[kgeist]

The main use case of generics is generic containers, and the two most popular generic containers - lists and maps - have always been part of the language (including their built-in generic functions). So in most cases, in a typical web project, you could indeed get away without generics entirely. Only in a few cases you'd be forced to use codegen/reflection/duplication - when you have to use complex algorithms which lists/maps can't satisfy. However, the Go team and the community had always been open to the idea of adding generics to the language (the official FAQ already in 2013 talked about potentially adding generics in the future), they just weren't sure how to implement them properly without overcomplicating the language (which is advertized as being simple), and generics can easily add a ton of complexity. So the introduction of generics was postponed because there were other more important features to iron out, considering that slices/maps already covered most cases. I think the breakthrough happened with the realization that code is more often read than written, so it's OK to make the language a little more complex for a library's author, most users won't see a considerable increase in complexity.

[Beltalowda]

> It was endless arguments from Go users that generics aren't needed

There was (and still is) a small minority of Go users that insist generics are bad, but in my observation it's nowhere near the majority view. As a concrete datapoint, the GitHub issue on this[1] has 2k upvotes and 150 downvotes. A sizeable minority, but a minority nonetheless.

As is often the case, "the Go community" is far from heterogeneous, and it's hard to really get an idea what "the average Go programmer" thinks, and easy to criticise the most extreme elements.

Certainly for the Go team itself the position was always that 1) generics are useful, but 2) we're not quite sure how to best implement them. Some people disagree with that viewpoint too, which is fair enough, but it's really quite a different one.

[1]: https://github.com/golang/go/issues/15292

[strken]

Not sure what you've been reading, but I've been reading lots of Go users who don't like generics arguing with lots of other Go users who do like generics. It's not a "those Go users" vs "us sensible people" flame war, it's a multifaceted debate with lots of sides, all of which contain some Go users.

[perbu]

I think you're misrepresenting the debate.

I've never seen anyone argue that generics aren't a useful concept, but I've seen plenty argue that it isn't worth the cost in incurs. That is a quite a different debate then the one you are outlining.

[oblio]

> plenty argue that it isn't worth the cost in incurs

The other "plenty" were arguing that it was worth the cost.

So color me surprised that this side was right.

[jonathanstrange]

There is no such thing as being right in such matters. Simplicity vs. expressivity is always a subjective trade-off. Otherwise, Zig could not possibly be a good language or Rust would obviously be a complete failure, for example, both of which seem like narrow-minded things to say. Sometimes more simplicity, sometimes more expressivity is better. It depends on for whom and for which tasks.

[oblio]

Golang competes in exactly the same space as Java and C#. With a small twist, but the same space.

That put a huge burden of proof on the Golang designers as the design space had been studied extensively for 3+ decades. And they skirted around that burden of proof for a while, I never liked their reasoning.

They could have just come out and said the didn't like generics and don't need them for their use cases.

Zig and Rust are in whole 'nother ballgame so there's no point involving them here.

[13415]

That's a bit of an old-school language flame war response. It seems obvious that there is no objective criterion for determining when a language is simple enough and when it isn't. Not everybody uses Go for the same hypothetical "design space", and the implicit claim in your post that the same criteria do not apply to Rust or Zig is also dubious, as if they couldn't possibly work as languages in the same "design space." We're talking about general purpose languages. To give you an example, Rust is overengineered and way too complex for my needs, it would seriously hamper productivity. It's important to be aware that other programmers' mileages differs.

The bottomline is that it's never fruitful to argue that feature sets that go into "simplicity" do not heavily depend on subjective programmer preferences, their tasks, and the intended application domains. Programming languages are mere tools, nothing else. Choose the one appropriate for your goals.