21–30 of 219 posts
Those Generics syntax in Golang seems so hard to read.
Am I the only one who’s absolutely shocked that Go finally is embracing generics? Does anyone have a bit of an inside view into what changed in the perspectives of the language maintainers? I’m not buying the “it took us 20 years to understand how to do it correctly” argument, as this is something you explicitly take into consideration when designing the language or not. And it was specifically not a part of language…
The Go ecosystem was a delicate, special thing. It was a wholesale rejection of the malignant consultancy takeover of programming that had festered and spread for the previous 15 years. Introducing generics was a grievous error, and they just keep making it worse.
It used to be you could look at any Go code from any author and pretty much instantly understand it completely. That’s no longer the case.
It used to be you would work on a problem, just writing the code from top to bottom. No time wasted fiddling with abstractions you’ll never use. You’d grumble about it, but succumbing to the temptation was impossible. That’s no longer the case.
Can generics be used to improve error handling and eliminate the if err pattern?
No. I kind of want to leave it there. But that will probably be looked on disfavorably. I've seen at least a dozen attempts. It's not like it's hard to write it out. There's maybe a couple of variants but they're all just a handful of lines. The problem is, once you have an Option in hand, you end up trading: val, err := whatever(...) if err != nil { // handle error } // use val for val := whatever(...) if err, isErr…
generics were a slippery slope. give it a decade and Go will be indistinguishable from c++
Lib boost will have conquered every language by then!!! :D
Jokes aside, generics are unusable in a lot of languages due to their syntax choices. In Go we kinda have the problem that there's no real templating and no real macros, so they're even harder to use.
But I agree somewhat, generics feels to me like an anti pattern in Go.
Also, the way the Go core/stdlib is written, it makes generics so unnecessarily painful to debug. Why they decided to have definitions like "~C" or "~[]S" is beyond me. No human knows what the resulting compile time error means. They should have named these things "Comparable" or "Slicable" or whatever is more expressive. Just stop with this stupid single letter shit.
generics were a slippery slope. give it a decade and Go will be indistinguishable from c++
I feel the sumtype/emum/routine demanders should yell a little harder so Go team can find their purpose again.
Am I the only one who’s absolutely shocked that Go finally is embracing generics? Does anyone have a bit of an inside view into what changed in the perspectives of the language maintainers? I’m not buying the “it took us 20 years to understand how to do it correctly” argument, as this is something you explicitly take into consideration when designing the language or not. And it was specifically not a part of language…
Unfortunately nothing changed. They wanted generics all along. The Go ecosystem was a delicate, special thing. It was a wholesale rejection of the malignant consultancy takeover of programming that had festered and spread for the previous 15 years. Introducing generics was a grievous error, and they just keep making it worse. It used to be you could look at any Go code from any author and pretty much instantly unders…
When I read these grumbling takes about how Go use to be so simple etc I imagine devs who would revel in all the features they were unable to implement because it would be too difficult in the language. Or devs who love typing and re-typing the same code over and over again, littering their code with switch cases and conditional logic while passing themselves on the back for avoiding “abstraction”.
Those Generics syntax in Golang seems so hard to read.
It is verbose but inference helps a lot to keep it “tidy”. I always find myself increasing my focus a notch when I start dealing with generics. It’s one of the things I use only if I really “need”.
Back when Go's generics came out, I was working with about 20% Go and 80% Python. I looked at the syntax, went "not today, Satan" and never bothered to learn it. For the past half year I've been in a mode where most of my coding time is spent with Go and I've been completely indoctrinated. I unironically like thinking about how generics and interfaces interact now.
I also need to slow down when I need to use them for non-trivial stuff. Not just relative to Go code but relative to how much I needed to think about them back when I was using OCaml. I think part of it is that I save them for hard issues and use interfaces for easy stuff.