[freyir]

I'm not sure who you're quoting or why.

> Issues are representative as a sampling, not absolute numbers.

My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it. I'll say it again:

>> The majority may not spend their time reading or reacting to proposals they don't care about.

Maybe the majority do want generics, but the Github issue is poor evidence. A random sample of Go developers would be much better, and then we wouldn't have to make up things like "And many more want Generics without having responded to the issue."

[coldtea]

>I'm not sure who you're quoting or why.

I accidentally re-pasted the same quote from nine_k I've answered to higher up the thread.

Meant to quote this from you: "1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that".

>* My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it.*

And my point is that I don't think this is the case. I don't know either way, but there's no reason to assume people caring to vote in the issue are necessarily not representative -- like I don't think that for any other project/issue combo on github.

In any case, even if they aren't representative of existing heavy Golang users, who cares about them? The language is still niche. There are tons more programmers to come to the language than those that already are using already.

So I would very much pay attention to what those not yet using it but caring enough to vote have to say about it.

[freyir]

Yeah, I would guess you're right, most existing (and potential) users would probably appreciate having generics.

[hackerfromthefu]

Speaking as someone who worked fulltime with C# when it was relatively simple in v1/1.1 which was before generics, and Object Pascal/Delphi for many years before then - when generics arrived in C# 2 it was a truly wonderful upgrade.

However the complexity of C# has exploded over the years, and it now lacks in simplicity, where Go shines. Yet I expect adding generics would improve Go as it certainly improved C#.

However the trick is knowing when to stop adding features, and with with the incredible pace of churn in most languages these days, it's a major competitive advantage to just not change the language. And advantage that would complement the simplicity of Go nicely.

(Of course it's theoretically possible for users to not upgrade as the language upgrades, but the reality is when the language changes it fragments the documentation, user base, and overall experience - so the argument for users not to upgrade, is not realistic.)

In chess there is the concept of a zugzwang, a situation where it's actually a dis-advantage to make a move. There's lots of other kitchen sink languages these days, Go may be best to keep building on the strength of it's simplicity, by simply not changing.