Hacker News new | past | comments | ask | show | jobs | submit login

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




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


> "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"?)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: