Hacker News Reader

Comment by tptacek | Hacker News Reader

"Finally". The Go devs have been talking about generics and the demand for generics for years. It's nobody's contention that people don't want them.

View on HN

Every second comment in discussions on the matter on HN ever is about how "people don't want them" and how those asking for them haven't really used Go to see how it doesn't need them in practice, and other such inanities.

It can obviously be simultaneously true that people don't find themselves needing generics in practice, but still want them in the language. Also, there's nothing "inane" about that.

Well, from my outside perspective there are certainly "Lack of generics is a feature" and "Generics are a feature that has not yet arrived" camps.

Again from an outside perspective, it also seems that these camps talk about their viewpoints to outsiders more than to each other.

Personally, I always thought the reality is probably closer to "Not adding generics prematurely is a design feature, and it hasn't moved forward yet since the core team doesn't need it enough, and no proposal developed critical mass of community support to consider it appropriately vetted."

No, the inane part I was referring to was the often heard notion that those that want Generics are not really Go users, else they would have seen that they are not needed.

Why would you want generics if you don't need them in practice?

Come on. You don't know the difference between needs and wants?

Discussing what you "need" isn't remotely interesting in the context of programming languages. You don't need anything more than assembly language to get anything done.

Redefining need as nice to have isn't interesting either. It should be possible for there to exist a set of features which are convenient if present, but the absence of which does not substantially impede the development of solutions.

You described a feature that good engineering practice says should be eliminated. Features have costs (the most significant of which IMO is learning an unfamiliar feature when you read other people's code), thus only features that allow better (less error prone, more maintainable, faster) implementation of applications should be included in any language.

Is the difference between "needs and wants" an engineering concept applicable to programming languages?

We're not talking about wanting the new iPhone or a Tesla here, it's about wanting something that simplifies code / improves the expressiveness of a language.

They're talking about them in the sense that they acknowledge the demand but still don't seriously pursue it. The constant answer of "well gee, we'd love to do generics but unfortunately there isn't a perfect solution that has zero tradeoffs, darn" isn't really "talking" so much as it's "dismissing".

Is there a way they can disagree with (presumably) you without being "dismissive", or to avoid that accusation do they simply need to implement some version of generics?

Reply on news.ycombinator.com