4 ms·

It's absolutely a possibility for Go 2.0. There's a hard lock on Go 1.X compatibility, but per the link in my above comment the Go team is fielding proposals fo

by Zikes 10y ago

It's absolutely a possibility for Go 2.0. There's a hard lock on Go 1.X compatibility, but per the link in my above comment the Go team is fielding proposals for Generic implementations. I also recommend reading Russ Cox's (Go core developer) HN comment: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417

glangdale 10y ago
I've read that before. I do regard the conservatism here as carrying a cost: specifically, great rafts of code will be written without generics and the absence of generics will influence other parts of the language. I'm not an expert in generics by any stretch of the imagination; I timidly implement the occasional template function, happily use STL/BGL where I can, and am amazed at the sort of data structures this lets me get away with. I do find myself puzzled that apparently no generics system in common use was deemed 'good enough' by the Go team to just clag before an entire language and its aforementioned 'rafts of code' sprang up around the absence of such features... there may be good reason. But a language that doesn't let me do what I happily do in C++, with type safety, using language features that are over a decade old, is a total non-starter for me. The language may be all the simpler for this, but the code I would have to write would bear the cost of this instead. It's not a win for me, and vague threats that I'll get a vomitous compiler message when I bugger up "make_pair" and hints that the "princess is in another castle" aren't going to browbeat me into accepting a throwback of a language. My guess is that g++'s template error messages are going to be acceptable long before I see generics in Go, if I ever do.
- Zikes 10y ago
  There's a great deal of discussion about Go generics that I linked, and I understand that it's quite a lot to ask anyone to read, so I want to sum it up as best I can: The Go team wants generics. They acknowledge that generics would be a benefit to the language, and they have acknowledged that generics are by far the most-requested language feature from full-time Go developers. The only thing stopping them from implementing Generics is the inherent (purely technical) difficulty in providing it in a correct, performant, and type-safe manner. The reason the Go team cannot look to Java, or Rust, or any other languages which provide generics and say "we will implement it exactly as they have" is because Go is as different from Java and Rust as Java is from Rust. Generics had to be individually implemented in each of those languages, and it was a fairly massive undertaking to do so, and there are a lot of folks that say that in Java's case in particular it was implemented poorly but now that it's implemented they're stuck with it. Like yourself I'm not an expert on generics, either, but everything I've read in regards to generics in Go has lead me to the above conclusion. I trust the Go core developers to implement generics when they have a suitable plan, and I will gladly use them when they are made available, but in the meantime I intend to enjoy all of the great features of the Go language which are available today.
  - jasonwatkinspdx 10y ago
    I preface this by saying I really like using go. > The only thing stopping them from implementing Generics is the inherent (purely technical) difficulty in providing it in a correct, performant, and type-safe manner. I initially accepted this, and found the "we don't want to build the wrong thing" explanation reasonable. Some years down the road however that's looking a bit threadbare. I've also read enough conversation threads that it's become very clear a couple of the key decision makers are simply resistant to the idea of consulting with the PLT community for a good design. I'm happy to wait to Go 2.0 for generics, however, if they yet again recycle this "gosh, it's hard, we just don't know how" I will not be satisfied. There are people walking this planet who know how: ask them.

by Zikes 10y ago

glangdale 10y ago

I've read that before. I do regard the conservatism here as carrying a cost: specifically, great rafts of code will be written without generics and the absence of generics will influence other parts of the language. I'm not an expert in generics by any stretch of the imagination; I timidly implement the occasional template function, happily use STL/BGL where I can, and am amazed at the sort of data structures this lets me get away with. I do find myself puzzled that apparently no generics system in common use was deemed 'good enough' by the Go team to just clag before an entire language and its aforementioned 'rafts of code' sprang up around the absence of such features... there may be good reason. But a language that doesn't let me do what I happily do in C++, with type safety, using language features that are over a decade old, is a total non-starter for me. The language may be all the simpler for this, but the code I would have to write would bear the cost of this instead. It's not a win for me, and vague threats that I'll get a vomitous compiler message when I bugger up "make_pair" and hints that the "princess is in another castle" aren't going to browbeat me into accepting a throwback of a language. My guess is that g++'s template error messages are going to be acceptable long before I see generics in Go, if I ever do.

Zikes 10y ago
There's a great deal of discussion about Go generics that I linked, and I understand that it's quite a lot to ask anyone to read, so I want to sum it up as best I can: The Go team wants generics. They acknowledge that generics would be a benefit to the language, and they have acknowledged that generics are by far the most-requested language feature from full-time Go developers. The only thing stopping them from implementing Generics is the inherent (purely technical) difficulty in providing it in a correct, performant, and type-safe manner. The reason the Go team cannot look to Java, or Rust, or any other languages which provide generics and say "we will implement it exactly as they have" is because Go is as different from Java and Rust as Java is from Rust. Generics had to be individually implemented in each of those languages, and it was a fairly massive undertaking to do so, and there are a lot of folks that say that in Java's case in particular it was implemented poorly but now that it's implemented they're stuck with it. Like yourself I'm not an expert on generics, either, but everything I've read in regards to generics in Go has lead me to the above conclusion. I trust the Go core developers to implement generics when they have a suitable plan, and I will gladly use them when they are made available, but in the meantime I intend to enjoy all of the great features of the Go language which are available today.
- jasonwatkinspdx 10y ago
  I preface this by saying I really like using go. > The only thing stopping them from implementing Generics is the inherent (purely technical) difficulty in providing it in a correct, performant, and type-safe manner. I initially accepted this, and found the "we don't want to build the wrong thing" explanation reasonable. Some years down the road however that's looking a bit threadbare. I've also read enough conversation threads that it's become very clear a couple of the key decision makers are simply resistant to the idea of consulting with the PLT community for a good design. I'm happy to wait to Go 2.0 for generics, however, if they yet again recycle this "gosh, it's hard, we just don't know how" I will not be satisfied. There are people walking this planet who know how: ask them.