Notes on the Go2 Generics Draft
jmoiron.net
Notes on the Go2 Generics Draft
1–10 of 116 posts
Re: Notes on the Go2 Generics Draft
#2The author makes some interesting arguments, but they are all predicated on the idea that generics are somehow hard to grok or use?
Having helped teach Java to many people with less than a year's programming experience at university, I refute this.
Bear in mind we're hardly talking about higher kinded types here. Generics are a simple abstraction over a lack of type information which allows you to write and maintain a lot less code; something which has been repeatedly demonstrated to reduce the incidence of bugs.
Personally, I am encouraged that the Go team is flexible enough to change their position. That gives me more confidence in the future of the language, not less.
Re: Notes on the Go2 Generics Draft
#3Yet another language tries to bolt on generics after the fact and finds that doing so results in awkwardness. Note to language designers: if you are creating a general purpose language, you will eventually need to add generics. You can either do it right at the beginning, or else you have to bolt it on at the end. Rust gets kudos in this regard for having well designed generics from the beginning.
Re: Notes on the Go2 Generics Draft
#4Its wonderful how much Go wants everyone to repeatedly develop container data structures. That way everyone gets their own artisanal bugs.
Re: Notes on the Go2 Generics Draft
#5The author makes some interesting arguments, but they are all predicated on the idea that generics are somehow hard to grok or use? Having helped teach Java to many people with less than a year's programming experience at university, I refute this. Bear in mind we're hardly talking about higher kinded types here. Generics are a simple abstraction over a lack of type information which allows you to write and maintain…
I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2.
What they repeatedly opposed was rushing generics into a v1.x build as that could break things.
The real issue is that many of the "haters" (and I hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go developers) didn't think the slow and methodical approach was good enough.
Sometimes it feels like those who are the loudest critics of Go aren't even Go developers and instead just like to shout about how amazing their preferences are because it does xyz differently. And frankly I get a little fed up with all the psuedo-religious zealotry some have towards programming languages. It's nuts. Yet that's exactly how many of the language-specific topics end up on HN and why many on here could be forgiven for not realising that the Go team have always been open minded about changing Go; they've just been stubborn about the timelines of such changes.
Re: Notes on the Go2 Generics Draft
#6Yet another language tries to bolt on generics after the fact and finds that doing so results in awkwardness. Note to language designers: if you are creating a general purpose language, you will eventually need to add generics. You can either do it right at the beginning, or else you have to bolt it on at the end. Rust gets kudos in this regard for having well designed generics from the beginning.
Rust has parametric polymorphism, not generics, and doesn't have subclasses. This makes it not quite the same thing.
Re: Notes on the Go2 Generics Draft
#7The author makes some interesting arguments, but they are all predicated on the idea that generics are somehow hard to grok or use? Having helped teach Java to many people with less than a year's programming experience at university, I refute this. Bear in mind we're hardly talking about higher kinded types here. Generics are a simple abstraction over a lack of type information which allows you to write and maintain…
> they are all predicated on the idea that generics are
> somehow hard to grok or use?
Re: Notes on the Go2 Generics Draft
#8Yet another language tries to bolt on generics after the fact and finds that doing so results in awkwardness. Note to language designers: if you are creating a general purpose language, you will eventually need to add generics. You can either do it right at the beginning, or else you have to bolt it on at the end. Rust gets kudos in this regard for having well designed generics from the beginning.
Rust has parametric polymorphism, not generics, and doesn't have subclasses. This makes it not quite the same thing.
Rust does have generics. There's little value in constructing a distinction between "templates", "generics" and "parametric polymorphism", at least not for the parent comment, which was likely intended to mean "Rust has a well designed system for working with 'unknown' types". (Also, maybe you could be specific about what you think the difference is.)
Go also doesn't have subclasses, so that doesn't seem relevant.
Re: Notes on the Go2 Generics Draft
#9The author makes some interesting arguments, but they are all predicated on the idea that generics are somehow hard to grok or use? Having helped teach Java to many people with less than a year's programming experience at university, I refute this. Bear in mind we're hardly talking about higher kinded types here. Generics are a simple abstraction over a lack of type information which allows you to write and maintain…
I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "hate…
> Sometimes it feels like those who are the loudest critics of Go aren't even Go developers
I have been writing Go exclusively for almost 3 years, (I still maintain some legacy J2EE applications, and live in a Java/C# town) -- this has been true anecdotally 99% of the time. There's the one-off who actually does use go regularly.
Then again, I witness this same phenomena in the JS framework battles, even within my own company. Vue vs React, where neither of them have ever used each others and built an actual production application to evaluate it. This is just the editor wars over again.
Re: Notes on the Go2 Generics Draft
#10The author makes some interesting arguments, but they are all predicated on the idea that generics are somehow hard to grok or use? Having helped teach Java to many people with less than a year's programming experience at university, I refute this. Bear in mind we're hardly talking about higher kinded types here. Generics are a simple abstraction over a lack of type information which allows you to write and maintain…
I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "hate…
> critics of Go aren't even Go developers
This doesn't make the criticism invalid. I tried Go, found the lack of genetics / gopath / depends management too annoying, went back to other languages. I'm going to try it again after V2 is released.
If only people continuing to use X could criticise X, we wouldn't get much progress.