51 ms·

First, I apologize for bringing up something that has been brought up since the birth of Go... I'm surprised at the lack of progress in generics for Go. But m

First, I apologize for bringing up something that has been brought up since the birth of Go... I'm surprised at the lack of progress in generics for Go. But more than progress, I'm surprised at the lack of a story about generics in Go. Yes, the FAQ waves its hands at complexity, but the lack of discussion and/or proposals puzzle me. The wiki page about it (https://code.google.com/p/go-wiki/wiki/GoVsGenerics https://code.google.com/p/go-wiki/wiki/GoVsGenerics) is tiny and feeds from this discussion (http://groups.google.com/group/golang-nuts/browse_thread/thread/3d825ac84e742598 http://groups.google.com/group/golang-nuts/browse_thread/thr...). I would be much more interested in Go were there some evidence for the intent to implement generics. A related concern is that adding generics will have a significant affect on libraries and existing code, so adding generics will become harder the longer Go waits. I would be very happy to have the Go team say: we're going to focus on adding generics to Go in 2.0 and will be considering how to get there sooner than later; that said, we don't know when 2.0 will be released, but building in generics will drive 2.0. Note: I understand the workarounds, but they're either hacky or have terrible performance. And I also understand that users of Go say that they don't miss generics, but I'm just not comfortable believing that.

gtaylor 13y ago
My understanding is/was that they'll get around to it eventually, but they're not in a hurry to rush it and stink it up. I haven't missed them too much in my tinkerings.
- joncooper 13y ago
  The sense I've gotten is that the Go team is surprised how little complaint has arisen among actual Go users about the lack of generics, and that that has kept the priority level low for figuring out how to implement them. In other words it seems like the Go team is actually slightly more interested in having them than the user base is. I'd like them in part because it'd enable all kinds of delightful reactive functional idioms that just aren't very possible currently. On the other hand I'm accomplishing an awful lot in Go without them..
  - justinsb 13y ago
    A sample set of "people that will tolerate the lack of generics" might be slightly biased on this question!
    - joncooper 13y ago
      For sure. On the other hand, one need not forgo an appreciation of fine Bordeaux simply because they enjoy shotgunning Coors Light.
      - stcredzero 13y ago
        True, but then one is more likely to be appreciating the extra effort of a craft brewer who knows how to get the benefit of really lively hops.
  - DougMerritt 13y ago
    > enable all kinds of delightful reactive functional idioms Link?
    - joncooper 13y ago
      https://www.coursera.org/course/reactive https://www.coursera.org/course/reactive
      - DougMerritt 13y ago
        Gee, an entire course on functional reactive programming rather than a link to the FRP idioms enabled by generics? For me? Gee thanks.
  - jerf 13y ago
    I don't care too much about the "delightful functional idioms" (on the grounds that merely adding generics to Go will still leave us pretty impoverished on that front anyhow) and doubt the Go team does, either. Probably the biggest and most visible pain point of missing generics is here: http://golang.org/pkg/container/ http://golang.org/pkg/container/ In particular, the pain point is that there aren't very many things there. Missing generics does not mean that no alternate data structures ever get written; as you can see, there are three of them there, which is greater than zero. However, it does mean they are more painful to use, consistently, everywhere, and no matter how much we'd all like to pretend we are infinitely disciplined programmers, pain matters, and in practice programmers visibly shy away from harder things. It is simply a fact that we must deal with. Generics missing from the language are a problem because it means that doing the right thing is harder than doing the wrong thing of just, say, using the wrong data structure because it's more convenient. A language (or an API or a library) should make right things easier and wrong things harder; it is a legit criticism when the right thing is impossible and the wrong thing (extensive copy & paste) is the only choice. Maps & slices are great and all, but they do not correctly cover all use cases, and the sort of servers that Go is otherwise very suitable for is also exactly where you might end up needing something other than those two things for performance reasons. I'm living without generics in Go, of course, because everyone programming in Go is. But I definitely see a lot of places here and there where I'm writing 5 lines extra, 10 lines extra, here, there, a little bit everywhere, that I simply should not have to write. Or, far worse, debug. Too often in Go I'm copying & pasting code where I should have generics, too often I'm fiddling with data structures at a lower level than I really need to.
justinsb 13y ago
I totally agree; I've "gone off Go" until they figure out (1) errors vs exceptions, and (2) generics. I have no problem with them saying "we're not Going there", but if so I wish they would at least say that. Right now, I'm betting at least one of those positions will change, and it will have fairly big ramifications for any existing code (in the same way that Java 1.0 code still runs, but is rather different code).
- joncooper 13y ago
  What is there to figure out about errors vs exceptions? I think the Go position on that matter is very clear.
  - justinsb 13y ago
    As I understand it, the position is that there are error return codes _and_ exceptions. Error return codes are for bad stuff, Exceptions are for really bad stuff. So correct Go code pays the price twice: it should be exception-safe, _and_ you have to manually handle error codes.
    - tptacek 13y ago
      Golang does not have exceptions. It has "panic", which, you can see from the name, is meant to end a program's execution and is presumably "recoverable" only so that programs can wind themselves down (more) gracefully.
      - justinsb 13y ago
        You say panic, I say exception :-) My concern is not nomenclature, but that correct code must handle paniceptions. And that it must also handle return value errors. Go code IMHO ends up spending a lot of code on error handling, I think because of this double taxation.
        tptacek 13y ago
tptacek 13y ago
There is a story about generics in Go. The story is, a variety of complex programs are being built and deployed in Golang without generics, which makes it an open question as to whether they're required at all. Golang doesn't have to be all things to all people, nor does it have to fulfill every programming task any one developer has. I would be just as happy at this point to see the Golang team put generics to rest. And I like generics, and have been annoyed by their absence in Golang before!
- voidlogic 13y ago
  >The story is, a variety of complex programs are being built and deployed in Golang without generics, which makes it an open question as to whether they're required at all. This. The same can be said for C as well, but C is not memory safe and Go is- so it wasn't immediately obvious the same would hold for Go. I used to use generics/templates in Java/C#/C++ a lot, and at first I missed them in Go, but now, after writing Go full time for 2+ years- I no longer miss them more than once or twice every few months... I think generics are great, but also greatly overused.
  - justinsb 13y ago
    Genuinely interested: do you have a trick for making sorting a collection less copy-and-pasty?
    - voidlogic 13y ago
      I made a bash script for this purpose, but I have actually only used it twice to be honest.
    - sandGorgon 13y ago
      could you elaborate - what is this about ? Go newbie here.
      - justinsb 13y ago
        To sort an array/collection in Go, you must implement an interface with 3 methods: https://gobyexample.com/sorting-by-functions https://gobyexample.com/sorting-by-functions It's boilerplate, which generic methods would avoid. There are shortcuts for sorting common types by their natural order in Go, so you only have to write this for custom types or custom orderings.
RamiK 13y ago
Before Generics, the Garbage Collector needs to be sorted out since that's what dictates the optimizations and abstractions in the rest of the safe code in a very significant way. e.g. Simple scope issues like "Do I allocate this array now, or inside the for loop" were still a question of Go 1.1 vs. Go 1.2... Then, once the GC is decided and realized, wouldn't you rather have Go self-compile so that the community could sprout experimental branches to test out different Generics approaches and designs? Especially since the Gophers themselves aren't too sure about the right approach here and want to get as much feedback as they can... TL;DR: It seems to me that the current trajectory of focusing primarily on the GC and self-compiling is the right way to go.
- jksmith 13y ago
  This
dualogy 13y ago
> but the lack of discussion I wouldn't say there has been a "lack of discussion" on generics at all..
ansible 13y ago
I do definitely want some kind of support for genetics in golang. I do understand and respect the difficulties the principal authors have with integrating it into the language as-is. There's actually a sort of workaround that I kind of liked: http://play.golang.org/p/LkVWkyph75 http://play.golang.org/p/LkVWkyph75 Discussion here: https://groups.google.com/forum/#!topic/golang-nuts/UyKree3BCQ0 https://groups.google.com/forum/#!topic/golang-nuts/UyKree3B... The basic approach is to define most of your generic data structure to use interface {}, and then have type-specific get/put and maybe comparison. This then minimizes the boilerplate code needed while retaining type safety. Implementing the generic functions requires a little more care than usual. But I think it is one of the best approaches for the language currently.
enneff 13y ago
We're still talking about generics. It might be sooner than 2.0. We have already said this several times.
naner 13y ago
I agree the worst thing about Go is the lack of generics. Not because of the missing functionality, but because you can't talk about go without somebody bringing up generics.
- deleted 13y ago
  [deleted]
- 3JPLW 13y ago
  Reminds me of the Python GIL.
  - ithkuil 13y ago
    Why?
    - 3JPLW 13y ago
      "Not because of the missing functionality, but because you can't talk about go without somebody bringing up [the GIL]." It's better these days, but for a while it was a common point of contention.
      - LBarret 13y ago
        it was slightly different: Anybody who wanted to try implementing a gil-less python could. The reasons of the status-quo were well explained. We only get hand-waving from the Go core devs.
        ithkuil 13y ago
        Adding generics to the language affects the language and reimplementing an interpreter/compiler for a language that fixes a performance issue without being incompatible are two completely different things.

gtaylor 13y ago

My understanding is/was that they'll get around to it eventually, but they're not in a hurry to rush it and stink it up. I haven't missed them too much in my tinkerings.

joncooper 13y ago
The sense I've gotten is that the Go team is surprised how little complaint has arisen among actual Go users about the lack of generics, and that that has kept the priority level low for figuring out how to implement them. In other words it seems like the Go team is actually slightly more interested in having them than the user base is. I'd like them in part because it'd enable all kinds of delightful reactive functional idioms that just aren't very possible currently. On the other hand I'm accomplishing an awful lot in Go without them..
- justinsb 13y ago
  A sample set of "people that will tolerate the lack of generics" might be slightly biased on this question!
  - joncooper 13y ago
    For sure. On the other hand, one need not forgo an appreciation of fine Bordeaux simply because they enjoy shotgunning Coors Light.
    - stcredzero 13y ago
      True, but then one is more likely to be appreciating the extra effort of a craft brewer who knows how to get the benefit of really lively hops.
- DougMerritt 13y ago
  > enable all kinds of delightful reactive functional idioms Link?
  - joncooper 13y ago
    https://www.coursera.org/course/reactive https://www.coursera.org/course/reactive
    - DougMerritt 13y ago
      Gee, an entire course on functional reactive programming rather than a link to the FRP idioms enabled by generics? For me? Gee thanks.
- jerf 13y ago
  I don't care too much about the "delightful functional idioms" (on the grounds that merely adding generics to Go will still leave us pretty impoverished on that front anyhow) and doubt the Go team does, either. Probably the biggest and most visible pain point of missing generics is here: http://golang.org/pkg/container/ http://golang.org/pkg/container/ In particular, the pain point is that there aren't very many things there. Missing generics does not mean that no alternate data structures ever get written; as you can see, there are three of them there, which is greater than zero. However, it does mean they are more painful to use, consistently, everywhere, and no matter how much we'd all like to pretend we are infinitely disciplined programmers, pain matters, and in practice programmers visibly shy away from harder things. It is simply a fact that we must deal with. Generics missing from the language are a problem because it means that doing the right thing is harder than doing the wrong thing of just, say, using the wrong data structure because it's more convenient. A language (or an API or a library) should make right things easier and wrong things harder; it is a legit criticism when the right thing is impossible and the wrong thing (extensive copy & paste) is the only choice. Maps & slices are great and all, but they do not correctly cover all use cases, and the sort of servers that Go is otherwise very suitable for is also exactly where you might end up needing something other than those two things for performance reasons. I'm living without generics in Go, of course, because everyone programming in Go is. But I definitely see a lot of places here and there where I'm writing 5 lines extra, 10 lines extra, here, there, a little bit everywhere, that I simply should not have to write. Or, far worse, debug. Too often in Go I'm copying & pasting code where I should have generics, too often I'm fiddling with data structures at a lower level than I really need to.

justinsb 13y ago

I totally agree; I've "gone off Go" until they figure out (1) errors vs exceptions, and (2) generics. I have no problem with them saying "we're not Going there", but if so I wish they would at least say that. Right now, I'm betting at least one of those positions will change, and it will have fairly big ramifications for any existing code (in the same way that Java 1.0 code still runs, but is rather different code).

joncooper 13y ago
What is there to figure out about errors vs exceptions? I think the Go position on that matter is very clear.
- justinsb 13y ago
  As I understand it, the position is that there are error return codes _and_ exceptions. Error return codes are for bad stuff, Exceptions are for really bad stuff. So correct Go code pays the price twice: it should be exception-safe, _and_ you have to manually handle error codes.
  - tptacek 13y ago
    Golang does not have exceptions. It has "panic", which, you can see from the name, is meant to end a program's execution and is presumably "recoverable" only so that programs can wind themselves down (more) gracefully.
    - justinsb 13y ago
      You say panic, I say exception :-) My concern is not nomenclature, but that correct code must handle paniceptions. And that it must also handle return value errors. Go code IMHO ends up spending a lot of code on error handling, I think because of this double taxation.
      - tptacek 13y ago

tptacek 13y ago

There is a story about generics in Go. The story is, a variety of complex programs are being built and deployed in Golang without generics, which makes it an open question as to whether they're required at all. Golang doesn't have to be all things to all people, nor does it have to fulfill every programming task any one developer has. I would be just as happy at this point to see the Golang team put generics to rest. And I like generics, and have been annoyed by their absence in Golang before!

voidlogic 13y ago
>The story is, a variety of complex programs are being built and deployed in Golang without generics, which makes it an open question as to whether they're required at all. This. The same can be said for C as well, but C is not memory safe and Go is- so it wasn't immediately obvious the same would hold for Go. I used to use generics/templates in Java/C#/C++ a lot, and at first I missed them in Go, but now, after writing Go full time for 2+ years- I no longer miss them more than once or twice every few months... I think generics are great, but also greatly overused.
- justinsb 13y ago
  Genuinely interested: do you have a trick for making sorting a collection less copy-and-pasty?
  - voidlogic 13y ago
    I made a bash script for this purpose, but I have actually only used it twice to be honest.
  - sandGorgon 13y ago
    could you elaborate - what is this about ? Go newbie here.
    - justinsb 13y ago
      To sort an array/collection in Go, you must implement an interface with 3 methods: https://gobyexample.com/sorting-by-functions https://gobyexample.com/sorting-by-functions It's boilerplate, which generic methods would avoid. There are shortcuts for sorting common types by their natural order in Go, so you only have to write this for custom types or custom orderings.

RamiK 13y ago

Before Generics, the Garbage Collector needs to be sorted out since that's what dictates the optimizations and abstractions in the rest of the safe code in a very significant way. e.g. Simple scope issues like "Do I allocate this array now, or inside the for loop" were still a question of Go 1.1 vs. Go 1.2... Then, once the GC is decided and realized, wouldn't you rather have Go self-compile so that the community could sprout experimental branches to test out different Generics approaches and designs? Especially since the Gophers themselves aren't too sure about the right approach here and want to get as much feedback as they can... TL;DR: It seems to me that the current trajectory of focusing primarily on the GC and self-compiling is the right way to go.

jksmith 13y ago
This

dualogy 13y ago

> but the lack of discussion I wouldn't say there has been a "lack of discussion" on generics at all..

ansible 13y ago

I do definitely want some kind of support for genetics in golang. I do understand and respect the difficulties the principal authors have with integrating it into the language as-is. There's actually a sort of workaround that I kind of liked: http://play.golang.org/p/LkVWkyph75 http://play.golang.org/p/LkVWkyph75 Discussion here: https://groups.google.com/forum/#!topic/golang-nuts/UyKree3BCQ0 https://groups.google.com/forum/#!topic/golang-nuts/UyKree3B... The basic approach is to define most of your generic data structure to use interface {}, and then have type-specific get/put and maybe comparison. This then minimizes the boilerplate code needed while retaining type safety. Implementing the generic functions requires a little more care than usual. But I think it is one of the best approaches for the language currently.

enneff 13y ago

We're still talking about generics. It might be sooner than 2.0. We have already said this several times.

naner 13y ago

I agree the worst thing about Go is the lack of generics. Not because of the missing functionality, but because you can't talk about go without somebody bringing up generics.

deleted 13y ago
[deleted]
3JPLW 13y ago
Reminds me of the Python GIL.
- ithkuil 13y ago
  Why?
  - 3JPLW 13y ago
    "Not because of the missing functionality, but because you can't talk about go without somebody bringing up [the GIL]." It's better these days, but for a while it was a common point of contention.
    - LBarret 13y ago
      it was slightly different: Anybody who wanted to try implementing a gil-less python could. The reasons of the status-quo were well explained. We only get hand-waving from the Go core devs.
      - ithkuil 13y ago
        Adding generics to the language affects the language and reimplementing an interpreter/compiler for a language that fixes a performance issue without being incompatible are two completely different things.