5 ms·

Adding generics to go was a mistake

gonzo41 3y ago
Considering what was done with Go before generics it's hard to disagree.
cy_hauser 3y ago
I've ended up using at least a half dozen generic helpers in every application I've written since they were added. They've made my coding easier, more concise, and help with testing. Adding generics to Go was well-founded.
- assbuttbuttass 3y ago
  Can you share some examples? I personally haven't found any excuses to use generics yet, so I'm curious where other people are finding them useful
  - shinies 3y ago
    Here is an example in the standard library: https://pkg.go.dev/slices https://pkg.go.dev/slices
    - assbuttbuttass 3y ago
      I've used the slices package and I agree it's useful. I was wondering more about generics use in application code
      - shinies 3y ago
        Before the slices package you had to write those functions for all your types, it's much better now! I also like using generics for API request/response code, ex: https://go.dev/play/p/OWf9eFmg1qF https://go.dev/play/p/OWf9eFmg1qF With generics you don't need to return any/interface{} / type assert at runtime
        assbuttbuttass 3y ago
        Hmm for this example I would be more inclined to use an output parameter rather than generics func Request(req, resp any) error { // send request (http, etc) b, err := json.Marshal(req) if err != nil { return err } log.Printf("sent request %+v - %s", req, b) // read response if err := json.Unmarshal([]byte(`{"success": false, "error": "invalid login"}`), resp); err != nil { return err } return nil } But I kind of agree it's nicer to use a return value rather than an output parameter. I'm excited to see what other new uses people come up with for generics!
cle 3y ago
Indeed, this was the exact stuff that I loved not having to deal with in Go: architecture astronauts pushing their code golf on everyone else. I’m quite sad to see this project as it demonstrates that Go is starting to lose many of the characteristics that attracted me to it in the first place. (For some context, I know quite a bit about functional programming and formal type theory, having studied the latter in grad school. It is intrinsically very interesting but I believe it is a net negative in most software engineering contexts.)
- wheelerof4te 3y ago
  "It is intrinsically very interesting but I believe it is a net negative in most software engineering contexts.)" Exactly, the place for FP was and always will be academia. Real programs require real, readable logic.
- jerf 3y ago
  "Nobody" uses this stuff in Go. I mean I'm sure it's not literally nobody, but I'm yet to encounter even one example of someone using this stuff in the wild. I'd love to be able to survey the authors of the dozen-ish variations on this posted over the last couple of years (most of the much less elaborate than this) and see how many of them are still using it in their real code. Again I'm sure the answer isn't literally zero but I bet it's statistically-significantly fewer than all of them.
  - cle 3y ago
    Saying no to generics sends a strong signal to FP astronauts to "take it somewhere else". This saying no to a huge number of things is the superpower of Go and its community IMO, but those "go away" signals are getting weaker over time, which increases the likelihood of needing conversations and decisions about when to use what style, which is exactly the sort of thing I enjoy not having to do with Go. For example: this entire HN thread. And all the other libraries you mention that keep soliciting conversations, nerd sniping people who could be spending that time making better products instead of quibbling over FP code golf. But maybe those folks will always find things to quibble over...

Considering what was done with Go before generics it's hard to disagree.

I've ended up using at least a half dozen generic helpers in every application I've written since they were added. They've made my coding easier, more concise, and help with testing. Adding generics to Go was well-founded.

assbuttbuttass 3y ago
Can you share some examples? I personally haven't found any excuses to use generics yet, so I'm curious where other people are finding them useful
- shinies 3y ago
  Here is an example in the standard library: https://pkg.go.dev/slices https://pkg.go.dev/slices
  - assbuttbuttass 3y ago
    I've used the slices package and I agree it's useful. I was wondering more about generics use in application code
    - shinies 3y ago
      Before the slices package you had to write those functions for all your types, it's much better now! I also like using generics for API request/response code, ex: https://go.dev/play/p/OWf9eFmg1qF https://go.dev/play/p/OWf9eFmg1qF With generics you don't need to return any/interface{} / type assert at runtime
      - assbuttbuttass 3y ago
        Hmm for this example I would be more inclined to use an output parameter rather than generics func Request(req, resp any) error { // send request (http, etc) b, err := json.Marshal(req) if err != nil { return err } log.Printf("sent request %+v - %s", req, b) // read response if err := json.Unmarshal([]byte(`{"success": false, "error": "invalid login"}`), resp); err != nil { return err } return nil } But I kind of agree it's nicer to use a return value rather than an output parameter. I'm excited to see what other new uses people come up with for generics!

cle 3y ago

Indeed, this was the exact stuff that I loved not having to deal with in Go: architecture astronauts pushing their code golf on everyone else. I’m quite sad to see this project as it demonstrates that Go is starting to lose many of the characteristics that attracted me to it in the first place. (For some context, I know quite a bit about functional programming and formal type theory, having studied the latter in grad school. It is intrinsically very interesting but I believe it is a net negative in most software engineering contexts.)

wheelerof4te 3y ago
"It is intrinsically very interesting but I believe it is a net negative in most software engineering contexts.)" Exactly, the place for FP was and always will be academia. Real programs require real, readable logic.
jerf 3y ago
"Nobody" uses this stuff in Go. I mean I'm sure it's not literally nobody, but I'm yet to encounter even one example of someone using this stuff in the wild. I'd love to be able to survey the authors of the dozen-ish variations on this posted over the last couple of years (most of the much less elaborate than this) and see how many of them are still using it in their real code. Again I'm sure the answer isn't literally zero but I bet it's statistically-significantly fewer than all of them.
- cle 3y ago
  Saying no to generics sends a strong signal to FP astronauts to "take it somewhere else". This saying no to a huge number of things is the superpower of Go and its community IMO, but those "go away" signals are getting weaker over time, which increases the likelihood of needing conversations and decisions about when to use what style, which is exactly the sort of thing I enjoy not having to do with Go. For example: this entire HN thread. And all the other libraries you mention that keep soliciting conversations, nerd sniping people who could be spending that time making better products instead of quibbling over FP code golf. But maybe those folks will always find things to quibble over...