Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Notes on the Go2 Generics Draft

jmoiron.net

Post reply on HN
Print view View original

11–20 of 116 posts

Re: Notes on the Go2 Generics Draft

#11

Post by skywhopper »

viraptor wrote: post #10
laumars wrote: post #5

Earlier quoted context omitted.

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.

Dependency management was always my pain point, but that has suddenly gotten crazy better with Go 1.11, for what it’s worth.

Re: Notes on the Go2 Generics Draft

#12

Post by SmirkingRevenge »

viraptor wrote: post #10
laumars wrote: post #5

Earlier quoted context omitted.

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.

Complaints about gopath always feel like such a nitpick to me. Environment variables are trivial. Few Languages are as simple as Go, when it comes to development environments.

Re: Notes on the Go2 Generics Draft

#13

Post by mcguire »

dbaupp wrote: post #8
Filligree wrote: post #6

Earlier quoted context omitted.

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.

They're the same thing:

"Generics" is a term from software engineering, describing how the concept is typically used.

"Parametric polymorphism" is a description from a type theoretic standpoint.

"Templates" are an implementation strategy.

Re: Notes on the Go2 Generics Draft

#14

Post by wwweston »

laumars wrote: post #5
hugofirth wrote: post #2

The 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

Perhaps unsurprisingly, those who didn't like what they saw when taking a look at Go might well have chosen to work in other languages.

This might be a basis on which to prioritize criticism -- certainly the criticisms of those who use a language are more important to those managing it than the complaints of those who don't use it -- but it's not a reasonable basis on which to disqualify criticism.

And to point a criticism back: sometimes it feels like some of Go's loudest defenders don't choose to offer the discussion much beyond that response ("you're not really using it because if you were you'd see that the pain point you're describing is imaginary or not that bad or has plans to make plans to be fixed").

I don't begrudge anyone who likes it their happiness using it. I know people who really do like it. But I know people who gave it a fair shot didn't like it. Mine was 9 months of part-time work on a project before I settled into the conclusion that most of MJD's faint praise of Java (https://blog.plover.com/prog/Java.html ) plus a few extra downsides applied to Go. Including, yes, the arguably generic-shaped hole.

I also don't begrudge the stewards of the language their own solution to that problem or their own timeline for it. Presumably a similarly generous spirit should apply to complaints continuing to register. If the pothole is still in the road, it isn't surprising that observations about it continue to roll in even after plans to develop plans to fix it may have been announced.

Re: Notes on the Go2 Generics Draft

#15

Post by viraptor »

SmirkingRevenge wrote: post #12
viraptor wrote: post #10

Earlier quoted context omitted.

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

Complaints about gopath always feel like such a nitpick to me. Environment variables are trivial. Few Languages are as simple as Go, when it comes to development environments.

It part of the death by papercuts for me. Sure, it's trivial, but it's the only language that requires it and I can't see any benefit of it. When working with multiple projects, it can lead to weird errors until you remember to change it too.

It's like getting a house where you have to use 2 separate switches to turn each light on/off. Is it a big deal? No. It's just weird and annoying, without an obvious benefit.

Re: Notes on the Go2 Generics Draft

#16

Post by coldtea »

laumars wrote: post #5
hugofirth wrote: post #2

The 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…

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

They said that occasionally, but always dismissing any kind of proposal that wasn't theirs, including perfectly fine existing paradigms from other languages, and always giving the impression to many people that they were just paying lip service to the idea that they are OK with eventually adding Generics, or stalling for time.

The fact that it took 10 years for this to finally come as a concrete suggestion (and not even with a final delivery date or official roadmap yet), means that they were indeed stalling for time.

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

This tired argument has been said again and again. Many seasoned go developers have spoken in favor of generics over the years. And this features was #1 in Go's own developers poll year after year.

Besides, it's not like non-users of a language are automatically wrong. If anything, they could be the ones seeing its faults more objectively (e.g. people calling out Java world's obsession with overusing patterns).

Re: Notes on the Go2 Generics Draft

#18

Post by coldtea »

Filligree wrote: post #6
RcouF1uZ4gsC wrote: post #3

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

Telling to the Rust team then:

https://doc.rust-lang.org/1.2.0/book/generics.html

https://doc.rust-lang.org/book/second-edition/ch10-01-syntax...

https://doc.rust-lang.org/rust-by-example/generics.html

Re: Notes on the Go2 Generics Draft

#19

Post by dbaupp »

mcguire wrote: post #13
dbaupp wrote: post #8

Earlier quoted context omitted.

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.

They're the same thing: "Generics" is a term from software engineering, describing how the concept is typically used. "Parametric polymorphism" is a description from a type theoretic standpoint. "Templates" are an implementation strategy.

I understand what these words mean... At least, I understand the variety of meanings they have: they're not always used to mean the same thing. For instance, people will rightly say that Java doesn't strictly have parametric polymorphism because of dynamic type casts, but they will say it has generics. Other people might draw a distinction between generics and templates, with the former being constrained (with type classes or similar) and the latter being macro-like.

However, I don't think these are actually particularly relevant to the original comment (and, I really think that Rust probably satisfies "generics" more than "parametric polymorphism", because one can also do generic casts).

Re: Notes on the Go2 Generics Draft

#20

Post by atombender »

SmirkingRevenge wrote: post #12
viraptor wrote: post #10

Earlier quoted context omitted.

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

Complaints about gopath always feel like such a nitpick to me. Environment variables are trivial. Few Languages are as simple as Go, when it comes to development environments.

The complaint about GOPATH is not that it's an environment variable. It's that it enforces a specific directory structure that does not match how most people organize their code trees.

Instead of a project being in a folder called, say, "foo", you end up with something like $HOME/go/src/github.com/bar/foo. Then, when you install your project's dependencies, they get commingled into this structure. If you do "ls $HOME/go/src", you'll see a ton of stuff polluting your tree, all of which are arguably build artifacts, not primary sources. Very few people manage their codebases like this. At best, you put all your dependencies under a subfolder somewhere so that there's no confusion.

Go 1.11 does away with GOPATH for your project, and relegates all the dependencies to $GOPATH/pkg/mod. We are now using this new module mode, and it's a breath of fresh air compared to the previous system. This way, Go feels a bit more modern and much less gnarly.

Post reply on HN