Hacker News Reader

Comment by grabcocque | Hacker News Reader

Are the Go devs finally starting to wake up to the realisation that maybe a better generics story, or less verbose and primitive error handling, is something people do, actually, want?

I get the impression the Go devs have been stoking the flames a bit by refusing to countenance the extension of the language even into areas where it was clearly lacking.

View on HN

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

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?

Eh ?

They've been researching ways to add generics to Go for a long time, here is some background:

https://research.swtch.com/go2017#generics

I have some sympathy here - generics is hard to get right, and language changes are forever. As a Go user, I have absolutely no problem with them taking their time on this and only introducing it (probably with Go 2) when it has been thoroughly thought through. There are workarounds (writing for specific types, go generate).

Generics have been around for decades. It seems very unlikely that Go will discover some entirely new way to implement them. They'll end up implementing them the same way they would have if they'd done it years ago. The tradeoffs are well known.

>I have some sympathy here - generics is hard to get right

What does "right" mean? All kinds of languages, even pet projects, managed to implement them just fine.

Except if we mean "perfect, in a way that avoids all engineering tradeoffs".

But why would Generics especially need to be perfect in a language full of other engineering tradeoffs?

Well they're listening... at least in the next couple of versions there should be an official dependency manager coming out. IMHO it's meh. They need to get rid of the damn gopath.

Between the new default GOPATH and the support for vendoring, I'm not sure I know what getting rid of the GOPATH would even mean anymore.

As a Go programmer since the 1.0 days, the concept of the GOPATH that existed when I started using the language is long gone.

vendor still doesn't work if your project is outside of GOPATH. The only thing the vendor folder is doing right now is precedence. Dep, the pre-alpha tool that is lining up to be the official dependency manager still doesn't work outside the GOPATH, hopefully they change that. The only thing that Go 1.8 did was add a default to GOPATH to $HOME/go.

In my ideal world, I should be able to clone a go project anywhere on my system, fetch the dependencies from the internet, yes the internet, because its 2017. (if you're that concerned with security fine, include them in your repo) but I should be able to call go build in that directory wherever it is.

Everyone involved in the technical decisionmaking agrees that, long term, the GOPATH will be deprecated and removed. The question is just about getting from here to there without fucking people's workflows too badly. It will probably be 2 or 3 more release cycles, at least, before that's a reality.

Reply on news.ycombinator.com