4 ms·

An open question: has the ship has already sailed on generics in Go? That is, is there too much Go code out there written without generics to ever incorporate g

An open question: has the ship has already sailed on generics in Go? That is, is there too much Go code out there written without generics to ever incorporate generics after-the-fact? I am in two minds; after all, C++ existed for a long time without a workable implementation of templates, and that hasn't stopped the STL from doing quite well. On the other hand, there were a number of fairly successful generics implementations already done when Go was created, and some of the core developers for Go seem to really have only lukewarm support for the idea (unlike C++, where Stroustrup seemed to support generics enthusiastically well before they appeared). It does seem to be a very weird thing to bolt onto an already mature language. Some of the less felicitous bits of the C++ standard library seem like they would have been done very differently if templates had worked from Day 1 in the language.

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.
jimsmart 10y ago
Generics weren't added to Java until J2SE 5.0 — which was years and years after 1.0, and Go is still 1.x, so I personally believe that ship is a long way from sailing.
gribbly 10y ago
>An open question: has the ship has already sailed on generics in Go? Doesn't seem so: https://research.swtch.com/go2017#generics https://research.swtch.com/go2017#generics >That is, is there too much Go code out there written without generics to ever incorporate generics after-the-fact? You don't HAVE to rewrite all existing code to using generics, although I'm sure it will be tempting :)

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.

jimsmart 10y ago

Generics weren't added to Java until J2SE 5.0 — which was years and years after 1.0, and Go is still 1.x, so I personally believe that ship is a long way from sailing.

gribbly 10y ago

>An open question: has the ship has already sailed on generics in Go? Doesn't seem so: https://research.swtch.com/go2017#generics https://research.swtch.com/go2017#generics >That is, is there too much Go code out there written without generics to ever incorporate generics after-the-fact? You don't HAVE to rewrite all existing code to using generics, although I'm sure it will be tempting :)