[yankput]

Adding generics to go was a mistake

[cle]

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.)

[jerf]

"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]

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...

[jerf]

The primary "conversations" that are spawned almost entirely consist of 1. people saying no thank you and 2. people expressing concern that this will become successful.

You can stop worrying about generics causing this.

Iterators may do a bit, but I still think that based on what is currently baking that people are going to find trying to do large amounts of work through iterators is not going to scratch their itch to do everything in a foreign paradigm.

If you want to work in a certain paradigm, then for pete's sake, do it. Go do it in a language where it's the best solution. Don't find the best solution in X, then try to jam it into Y at all costs. This isn't special to X = Haskell and Y = Go, it's true for all combinations of languages.

[wheelerof4te]

"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.

[cy_hauser]

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]

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]

Here is an example in the standard library: https://pkg.go.dev/slices

[assbuttbuttass]

I've used the slices package and I agree it's useful. I was wondering more about generics use in application code

[shinies]

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

With generics you don't need to return any/interface{} / type assert at runtime

[assbuttbuttass]

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!

[gonzo41]

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