[burntsushi]

> That link has been debunked over and over and over.

The only point that post is making is that generics have a cost. Are you saying that is false?

> Being dishonest will just alienate even more people.

What are you hoping to achieve by insulting a large group of people? If your goal is to alienate them, then surely that is an effective tactic.

[frowaway001]

> The only point that post is making is that generics have a cost. Are you saying that is false?

Did you actually read the article?

> The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?

Wrong.

Additionally, not having Generics has a cost, too. People might disagree which cost is higher (Generics vs. no Generics), but acting as if there was a lower cost solution of "no Generics now, but retroactively add them later" hiding somewhere is just incredibly disingenuous and delusional.

Given your cost argument, there is absolutely no position under which "we don't have plan, but might consider it in the future" would give a favorable outcome. Why not just be honest and tell your users that Generics will never arrive?

> What are you hoping to achieve by insulting a large group of people? If your goal is to alienate them, then surely that is an effective tactic.

Oooooh. Burntsushi pulling his "whine whine you weren't nice to me first!", how unexpected ... not. It's a fascinating pattern which happens as soon as you run out of on-topic arguments.

[burntsushi]

> Additionally, not having Generics has a cost, too.

The article says it: "do you want slow programmers, slow compilers and bloated binaries, or slow execution times." The first "slow programmers" cost is addressing the absence of generics in the language. Thus, it admits a cost.

> but acting as if there was a lower cost solution of "no Generics now, but retroactively add them later" hiding somewhere is just incredibly disingenuous and delusional.

... Nobody is acting that way. I've said nothing about the relative weight of any cost, nor have I claimed that a lack of generics has no cost. I mean, the link I gave you admits that a lack of generics has a cost right there. You even quoted the relevant portion.

> Given your cost argument, there is absolutely no position under which "we don't have plan, but might consider it in the future" would give a favorable outcome. Why not just be honest and tell your users that Generics will never arrive?

I don't understand what point you're trying to make. Are you saying that the Go language maintainers are purposefully lying to everyone? Do you have evidence of this claim?

> It's a fascinating pattern which happens as soon as you run out of on-topic arguments.

And insulting people doesn't fit that pattern? Yikes.

[dragonwriter]

> Given your cost argument, there is absolutely no position under which "we don't have plan, but might consider it in the future" would give a favorable outcome.

Sure there are, including the following possibilities: 1) There are situations in which generics are a net benefit and situations in which generics are a net cost, and currently Go's target are is the latter, but because of drift in what people what in given domains, it evolves toward the former, 2) New advances in understanding of language design and implementation change the tradeoffs of generics such that they are a net benefit in places where currently they are a net cost, 3) The reason generics are a net cost in the current situation of Go isn't fundamental as a featre, but a matter of opportunity cost given other things that were and are being implemented in Go that implementing generics would tradeoff. A future implementation that doesn't disrupt non-generic-using code once other higher-priority features are implemented wouldn't be a net cost. But that's farther out than Go's current roadmap.

> Why not just be honest and tell your users that Generics will never arrive?

Because its not honest to state a decision that hasn't actually been made.

[frowaway001]

> New advances in understanding of language design and implementation [...]

"New advances" as in "the last 50 years of progress in language design which we have conveniently ignored"?

There are languages from the 60ies which are better than Go (but lacked Go's distinguishing feature, the Google brand).

> Because its not honest to state a decision that hasn't actually been made.

Given the constraints they have already made a decision.

[dragonwriter]

> "New advances" as in "the last 50 years of progress in language design which we have conveniently ignored"?

No, new advances as in, "new advances". The universe changes, and the context in which the decision not to prioritize generics now was made is not fixed.

> There are languages from the 60ies which are better than Go

"Better" is both subjective and use dependent, and, in any case, that claim is irrelevant to the point under discussion, which is whether or not it is logically possible for the cost tradeoffs to disfavor generics in Go now but favor them in the future.

> Given the constraints they have already made a decision.

Given the current constraints they have already made a decision not to develop generics now.

They have not made the decision you claim that they would be "honest" to announce, to wit, that Go will never have generics.

It may be that it won't, but that's a not a decision that they have made (nor is it a decision that it would likely ever make sense to make. Why ever say "never"?)