5 ms·

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 pe

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.

rem7 10y ago
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.
- chimeracoder 10y ago
  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.
  - rem7 10y ago
    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.
- sagichmal 10y ago
  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.
tptacek 10y ago
"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.
- coldtea 10y ago
  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.
  - tptacek 10y ago
    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.
    - phaylon 10y ago
      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."
    - coldtea 10y ago
      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.
    - pcwalton 10y ago
      Why would you want generics if you don't need them in practice?
grey-area 10y ago
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).
- MichaelGG 10y ago
  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.
- coldtea 10y ago
  >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?
gribbly 10y ago
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 https://research.swtch.com/go2017#generics

rem7 10y ago

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.

chimeracoder 10y ago
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.
- rem7 10y ago
  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.
sagichmal 10y ago
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.

tptacek 10y ago

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

coldtea 10y ago
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.
- tptacek 10y ago
  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.
  - phaylon 10y ago
    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."
  - coldtea 10y ago
    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.
  - pcwalton 10y ago
    Why would you want generics if you don't need them in practice?

grey-area 10y ago

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

MichaelGG 10y ago
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.
coldtea 10y ago
>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?

gribbly 10y ago

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 https://research.swtch.com/go2017#generics