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