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

[oblio]

> We're talking about general purpose languages.

Well, kind of. But in practice, you have to agree that even theoretically "general purpose languages" either fall or get pushed into niches.

For example, Ruby. In real life, mass usage, Ruby is at this point a 1-trick pony, web apps with Rails. While Rails was the rage, it tried and did break out into DevOps, but all those efforts have kind of fallen by the wayside (Chef - a shame, really, Puppet, etc).

Another example, Rust is a general programming language, but few people will actually use it for Line of Business GUI apps, for example. It's just too hard to get started with it and there's no point, you gain too little from its advantages to work so hard through that learning curve.

Same thing for Java and C#. Most companies that will hire you to write something in those languages will probably do it for backend services, plus Java Android apps because Google chose it for that (and then chose Kotlin) and C# Windows apps (but how many people are really writing those these days?). For Go almost everything I've seen is also for backend services.

So in day-to-day life they are direct competitors. Kudos to Go that it got this far and we're putting it into the same league with Java and C#, it's quite an achievement!

I do agree with your principle but in practice most projects are brownfield and your tools have already been chosen by someone else :-)

[KerrAvon]

In fairness, “all languages are tools; choose the most appropriate one for your task” is also an old-school language flamewar response.