5 ms·

I have never needed generics in Go, and I've probably been using it since 2017. I've never even once had to resort to any interface{} trickery to express what I

I have never needed generics in Go, and I've probably been using it since 2017. I've never even once had to resort to any interface{} trickery to express what I want, and I've written Go programs for Fortune 50 companies, as well as complex personal projects such as AST parsers/code generators. I'm pretty disappointed to see generics introduced into the language and every example I've seen feels completely unreadable to me compared to pre-generics implementations. To be clear, it has never been the case that the Golang authors were 100% against generics. It has always been their position that the implementation needed to be good enough to make the trade-offs worthwhile. I just don't think they chose the right trade-offs.

qaq 5y ago
never needed min/max ?
- horsemans 5y ago
  Would you use generics to write the same implementation of min/max for integers and floats?
  - grey-area 5y ago
    You certainly might use them to write a facade which made life easier for consumers of the math pkg and accept floats,ints or uints even if behind the scenes it splits into different implementations.
    - horsemans 5y ago
      I would not be very happy if every time I called math.Min, I was also, under the hood, calling reflect.TypeOf.
      - danachow 5y ago
        The whole point of generics is to avoid this - why do you think you would have to use reflection?
  - qaq 5y ago
    The fact that you would not need a separate one for each of the: uint8 , uint16 , uint32 , uint64 , int8 , int16 , int32, int64 is not enough ?
  - Groxx 5y ago
    Absolutely, yes. It's downright trivial: https://gotipplay.golang.org/p/XF6wM3JF2QM https://gotipplay.golang.org/p/XF6wM3JF2QM From https://itnext.io/generics-in-golang-1-18-no-need-to-write-max-min-anymore-maybe-d79f3392ca38 https://itnext.io/generics-in-golang-1-18-no-need-to-write-m...
    - danachow 5y ago
      This is a joke, right? Your trivial implementation isn't even correct.
      - Jtsummers 5y ago
        https://gotipplay.golang.org/p/N2v8aB1tUtN https://gotipplay.golang.org/p/N2v8aB1tUtN Is this one better? It does run and doesn't rely on casting (not sure why GP's source took that route, it was lossy and kind of dumb). I suspect the compilation problem was because of a change in the syntax between when that was created and today.
        Groxx 5y ago
        yeah, it's just old. the `~int | ~float32 | etc` syntax is relatively recent.
        deleted 5y ago
        [deleted]
  - danachow 5y ago
    Why not? You later seem to think that this would require reflection - but that makes it apparent you don't understand how generics work in a language. They're used at compile time - to avoid runtime checking.
kodablah 5y ago
> I've never even once had to resort to any interface{} trickery to express what I want, and I've written Go programs for Fortune 50 companies, as well as complex personal projects such as AST parsers/code generators. That's pretty surprising to me. Have you never had to implement marshalers for unknown types and such? I have had to implement things like json.Marshal and json.Unmarshal for different encodings dozens of times in my Go tenure. I have had to use reflection a lot. I have had to deserialize into map[string]interface{} to handle ambiguous situations at runtime a lot. Have you never even had to wrap or build your own Printf equivalents that accept interface{}? No loggers? No custom containers? None of that which operates on unknown types? I see use of interface{} all over the vast majority of Go projects. I think your experience may be atypical.
- flippinburgers 5y ago
  His experience coincides with my own having solved many business level problems using golang for several years. At most I have used non-empty interfaces to solve very few number of issues (countable on one hand). I have never needed interface{}.
- horsemans 5y ago
  It's entirely possible that, through some strange quirks of circumstance, I've managed to avoid every problem space that would make me wish for generics. In spite of that, it's unlikely that I've written implementations where using interface{} would be easier to read and reason about than not using interface{}. And the experience of the author whose blog post we're commenting on tracks with mine: "In my 5+ years working in Go, I can probably count on one hand the number of times that I felt like I really needed generics." I can too, just without using any fingers :-)
  - kodablah 5y ago
    I feel the similar way, though I wouldn't be so brave to say I didn't ever use interface{}. I think we all work around slices and maps being the only generic containers and don't know we do. I think everyone will find that while they didn't need generics, they will help them when using utility libraries. Java 1.4 people thought the same. I expect well-curated libraries to come about that will really simplify some otherwise difficult problems for people (e.g. task/object pooling). I'm even toying with a futures impl at https://github.com/cretz/fut https://github.com/cretz/fut, but I wouldn't use it in place of channels in most cases.
grey-area 5y ago
There are areas where they will help, and be pretty transparent to the user, lots of places in the stdlib, one trivial example: math.Max(a,b) could take any numeric instead of just float64, sort could be neater etc. Perhaps a Go 2 if they ever get there could be a generic std lib rewrite, largely transparent to the end user, with some minor incompatibilities allowed and lots of stuff rewritten behind the scenes. They could remove a few ugly corners in the stdlib naming specific types by using generics, add a few more container types perhaps, deprecate some old stuff and move it out.
- hnlmorg 5y ago
  I'm hoping Go 2 replaces the file struct with an interface too. That's been a particular pain point for me.
  - cpuguy83 5y ago
    You mean like https://pkg.go.dev/io/fs#File https://pkg.go.dev/io/fs#File?
    - hnlmorg 5y ago
      Sorry I should have been more specific. I mean the os file struct https://pkg.go.dev/os#File https://pkg.go.dev/os#File The os package makes use of a *File struct rather than an interface. The authors acknowledged this was a mistake but it's some of the oldest code in Go and Go's backwards compatibility guarantee has meant that they cannot fix that. Since I author a $SHELL written in Go, being able to add in my own *File methods would have allowed me to add in some cool features. But I've found workarounds in most cases. It's just not as clean code as it could have been.
      - cpuguy83 5y ago
        What I am saying is, there is already an interface, which os.File should be implementing.
hnlmorg 5y ago
> as well as complex personal projects such as AST parsers/code generators. Funny you say that because for me that's the one use case I have for generics. (edit: why the hell am I getting downvoted for posting a fact? I wasn't offensive, argumentative, etc. Just citing one example I've run into where generics would help me personally)

qaq 5y ago

never needed min/max ?

horsemans 5y ago
Would you use generics to write the same implementation of min/max for integers and floats?
- grey-area 5y ago
  You certainly might use them to write a facade which made life easier for consumers of the math pkg and accept floats,ints or uints even if behind the scenes it splits into different implementations.
  - horsemans 5y ago
    I would not be very happy if every time I called math.Min, I was also, under the hood, calling reflect.TypeOf.
    - danachow 5y ago
      The whole point of generics is to avoid this - why do you think you would have to use reflection?
- qaq 5y ago
  The fact that you would not need a separate one for each of the: uint8 , uint16 , uint32 , uint64 , int8 , int16 , int32, int64 is not enough ?
- Groxx 5y ago
  Absolutely, yes. It's downright trivial: https://gotipplay.golang.org/p/XF6wM3JF2QM https://gotipplay.golang.org/p/XF6wM3JF2QM From https://itnext.io/generics-in-golang-1-18-no-need-to-write-max-min-anymore-maybe-d79f3392ca38 https://itnext.io/generics-in-golang-1-18-no-need-to-write-m...
  - danachow 5y ago
    This is a joke, right? Your trivial implementation isn't even correct.
    - Jtsummers 5y ago
      https://gotipplay.golang.org/p/N2v8aB1tUtN https://gotipplay.golang.org/p/N2v8aB1tUtN Is this one better? It does run and doesn't rely on casting (not sure why GP's source took that route, it was lossy and kind of dumb). I suspect the compilation problem was because of a change in the syntax between when that was created and today.
      - Groxx 5y ago
        yeah, it's just old. the `~int | ~float32 | etc` syntax is relatively recent.
      - deleted 5y ago
        [deleted]
- danachow 5y ago
  Why not? You later seem to think that this would require reflection - but that makes it apparent you don't understand how generics work in a language. They're used at compile time - to avoid runtime checking.

kodablah 5y ago

> I've never even once had to resort to any interface{} trickery to express what I want, and I've written Go programs for Fortune 50 companies, as well as complex personal projects such as AST parsers/code generators. That's pretty surprising to me. Have you never had to implement marshalers for unknown types and such? I have had to implement things like json.Marshal and json.Unmarshal for different encodings dozens of times in my Go tenure. I have had to use reflection a lot. I have had to deserialize into map[string]interface{} to handle ambiguous situations at runtime a lot. Have you never even had to wrap or build your own Printf equivalents that accept interface{}? No loggers? No custom containers? None of that which operates on unknown types? I see use of interface{} all over the vast majority of Go projects. I think your experience may be atypical.

flippinburgers 5y ago
His experience coincides with my own having solved many business level problems using golang for several years. At most I have used non-empty interfaces to solve very few number of issues (countable on one hand). I have never needed interface{}.
horsemans 5y ago
It's entirely possible that, through some strange quirks of circumstance, I've managed to avoid every problem space that would make me wish for generics. In spite of that, it's unlikely that I've written implementations where using interface{} would be easier to read and reason about than not using interface{}. And the experience of the author whose blog post we're commenting on tracks with mine: "In my 5+ years working in Go, I can probably count on one hand the number of times that I felt like I really needed generics." I can too, just without using any fingers :-)
- kodablah 5y ago
  I feel the similar way, though I wouldn't be so brave to say I didn't ever use interface{}. I think we all work around slices and maps being the only generic containers and don't know we do. I think everyone will find that while they didn't need generics, they will help them when using utility libraries. Java 1.4 people thought the same. I expect well-curated libraries to come about that will really simplify some otherwise difficult problems for people (e.g. task/object pooling). I'm even toying with a futures impl at https://github.com/cretz/fut https://github.com/cretz/fut, but I wouldn't use it in place of channels in most cases.

grey-area 5y ago

There are areas where they will help, and be pretty transparent to the user, lots of places in the stdlib, one trivial example: math.Max(a,b) could take any numeric instead of just float64, sort could be neater etc. Perhaps a Go 2 if they ever get there could be a generic std lib rewrite, largely transparent to the end user, with some minor incompatibilities allowed and lots of stuff rewritten behind the scenes. They could remove a few ugly corners in the stdlib naming specific types by using generics, add a few more container types perhaps, deprecate some old stuff and move it out.

hnlmorg 5y ago
I'm hoping Go 2 replaces the file struct with an interface too. That's been a particular pain point for me.
- cpuguy83 5y ago
  You mean like https://pkg.go.dev/io/fs#File https://pkg.go.dev/io/fs#File?
  - hnlmorg 5y ago
    Sorry I should have been more specific. I mean the os file struct https://pkg.go.dev/os#File https://pkg.go.dev/os#File The os package makes use of a *File struct rather than an interface. The authors acknowledged this was a mistake but it's some of the oldest code in Go and Go's backwards compatibility guarantee has meant that they cannot fix that. Since I author a $SHELL written in Go, being able to add in my own *File methods would have allowed me to add in some cool features. But I've found workarounds in most cases. It's just not as clean code as it could have been.
    - cpuguy83 5y ago
      What I am saying is, there is already an interface, which os.File should be implementing.

hnlmorg 5y ago

> as well as complex personal projects such as AST parsers/code generators. Funny you say that because for me that's the one use case I have for generics. (edit: why the hell am I getting downvoted for posting a fact? I wasn't offensive, argumentative, etc. Just citing one example I've run into where generics would help me personally)