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

Go 1.5 Release Notes

tip.golang.org

Post reply on HN
Print view View original

51–60 of 66 posts

Re: Go 1.5 Release Notes

#51

Post by NateDad »

flohofwoe wrote: post #48
NateDad wrote: post #44

The "stop the world" phase of the collector will almost always be under 10 milliseconds and usually much less. ...and all of a sudden, GC becomes a non-issue for all but the most highly performing software.

10ms is still a gargantuan amount of time for any type of application that must present a smoothly animated UI (not just games), about 60% of the per-frame budget. Every frame where the GC decides to kick in would result in a skipped frame, which is very noticeable. The only acceptable type of garbage collector for this type of application (and I wouldn't call an animated UI application a "most highly performing soft…

If you'd seen the graphs you'd see that the stop time is related to total memory used. 10ms only happens with a large number of gigs of memory being used. For more reasonable amounts (up to a few gigs) the stop times are 1-3ms.

Re: Go 1.5 Release Notes

#52

Post by coldtea »

crawshaw wrote: post #49
pcwalton wrote: post #38

Earlier quoted context omitted.

> I haven't seen any rejoinders to that document that contradict the fact that you pay for parametric polymorphism with either slower compilation or slower runtime. I think the error in that reasoning is attributing this issue to generics specifically when this is actually a problem with code reuse in general. Say I have a linked list and want to use it to hold both integers or strings. My two options, in any languag…

That is a powerful theoretical concern that I shared when I first experimented with Go several years ago. In practice I have not found it to not be a problem. It seems (and this is purely an analysis of my own experience and the large amount of Go I read inside Google) that the types of data structures and algorithms I need parametrized follow a power law distribution. Mostly I need a list, or a hash map, and the bui…

>That is a powerful theoretical concern that I shared when I first experimented with Go several years ago. In practice I have not found it to not be a problem.

People that didn't find it to be a problem (e.g. due to the kind of stuff they are working on) are not the ones concerned about its lack though.

It's like someone saying "I just do web development with Python, so I see no reason for NumPy to exist".

Re: Go 1.5 Release Notes

#53

Post by coldtea »

skybrian wrote: post #41
coldtea wrote: post #32

Earlier quoted context omitted.

> Russ Cox said this year that generics aren't left out because of political reasons or design choice. They've been saying that from the begining. There are no real technical constraints, it's been done in all kinds of languages and it has been a well understood feature for 2+ decades. They just don't want to do the compromises needed, while letting the developers continue to deal with all of them... See also pcwalto…

They've been solved for many other languages but not for Go. The lessons learned don't necessarily translate well between languages, because different problems need to be solved. Each language is a bag of features that need to work well with all the other features included in the language.

Do you find Go imposing any special set of contraints? If anything is far less featureful and Algol-like than most of the other languages that have found a way to fit Generics.

Re: Go 1.5 Release Notes

#54

Post by pcwalton »

crawshaw wrote: post #49
pcwalton wrote: post #38

Earlier quoted context omitted.

> I haven't seen any rejoinders to that document that contradict the fact that you pay for parametric polymorphism with either slower compilation or slower runtime. I think the error in that reasoning is attributing this issue to generics specifically when this is actually a problem with code reuse in general. Say I have a linked list and want to use it to hold both integers or strings. My two options, in any languag…

That is a powerful theoretical concern that I shared when I first experimented with Go several years ago. In practice I have not found it to not be a problem. It seems (and this is purely an analysis of my own experience and the large amount of Go I read inside Google) that the types of data structures and algorithms I need parametrized follow a power law distribution. Mostly I need a list, or a hash map, and the bui…

You shifted the argument from "generics are either bad for compile time or bad for performance, and therefore bad for Go" to "I don't need generics". I can't argue that you need generics, since I don't know the code you're writing (though I think it's likely you're leaving a good deal of performance on the table). But I do think the former problem has little to do with generics as a language feature.

Re: Go 1.5 Release Notes

#55

Post by crawshaw »

pcwalton wrote: post #54
crawshaw wrote: post #49

Earlier quoted context omitted.

That is a powerful theoretical concern that I shared when I first experimented with Go several years ago. In practice I have not found it to not be a problem. It seems (and this is purely an analysis of my own experience and the large amount of Go I read inside Google) that the types of data structures and algorithms I need parametrized follow a power law distribution. Mostly I need a list, or a hash map, and the bui…

You shifted the argument from "generics are either bad for compile time or bad for performance, and therefore bad for Go" to "I don't need generics". I can't argue that you need generics, since I don't know the code you're writing (though I think it's likely you're leaving a good deal of performance on the table). But I do think the former problem has little to do with generics as a language feature.

My goal was to explain how I make do with the features that exist (paying one of the tradeoffs, productivity, compile time, or runtime), and that any more general purpose implementation of generics would, to be orthogonal with existing features, necessarily slow compilation (because it would have to take over the job of slices and maps today, and would become prevalent in our APIs).

I'm not trying to shift the argument, I'm to explain the importance of Go in practice. There is a generics dilemma that programmers pay today and it should be possible to turn that into a language feature with the same tradeoffs. In practice, I don't think a generics language feature that captures how I program in Go is possible. (Or at least, I haven't thought of one nor seen a proposal that does.)

Like many others, I'd like to see a prototype that proves me wrong.

Re: Go 1.5 Release Notes

#56

Post by ansible »

coldtea wrote: post #53
skybrian wrote: post #41

Earlier quoted context omitted.

They've been solved for many other languages but not for Go. The lessons learned don't necessarily translate well between languages, because different problems need to be solved. Each language is a bag of features that need to work well with all the other features included in the language.

Do you find Go imposing any special set of contraints? If anything is far less featureful and Algol-like than most of the other languages that have found a way to fit Generics.

Go does have some things like interfaces that don't work quite like they do in other languages.

I have yet to see a full technical proposal that integrates well with the existing language features and has no nasty corner cases. If such a thing existed, I'd be among the first to stand up and applaud it.

The best solution currently (IMHO), is code generation with things like gen [1]. Though I have yet to use that in a real project, so I can't say for sure it is actually the best solution.

[1] https://clipperhouse.github.io/gen/

Re: Go 1.5 Release Notes

#57

Post by coldtea »

crawshaw wrote: post #36
coldtea wrote: post #33

Earlier quoted context omitted.

All of the supposed reasons given in that post have been answered to death by multiple people (including PL experts), and none holds to much scrutiny. "We just can't be bothered" or "we don't think they're much good, and we don't have a need for them" would be a much more realistic answer.

I haven't seen any rejoinders to that document that contradict the fact that you pay for parametric polymorphism with either slower compilation or slower runtime. Go isn't interested in either being slow. Any generics solution has to have fast runtime, because they need to replace the builtin parametric slices and maps. And the compiler is already too slow, in fact there's a lot of work slated to try and make it fast…

>Lots of effort went into studying the problem, so it most definitely isn't an issue of "can't be bothered".

Citation needed.

I've seen absolutely zero sample implementations, testing of implementation options, etc work going in with regard to adding Generics in Go.

And, aside from a couple of blog posts and shooting down people asking for it in comments, I've seen no real organized discussion, e.g. like what would go on for a Python PEP to be accepted.

Re: Go 1.5 Release Notes

#58

Post by pcwalton »

NateDad wrote: post #44

The "stop the world" phase of the collector will almost always be under 10 milliseconds and usually much less. ...and all of a sudden, GC becomes a non-issue for all but the most highly performing software.

That's highly oversimplified. It traded throughput for pause time.

(Pause time is not the only metric that matters; thinking that it is is a common misconception about GC that bugs me.)

Re: Go 1.5 Release Notes

#59

Post by pcwalton »

crawshaw wrote: post #55
pcwalton wrote: post #54

Earlier quoted context omitted.

You shifted the argument from "generics are either bad for compile time or bad for performance, and therefore bad for Go" to "I don't need generics". I can't argue that you need generics, since I don't know the code you're writing (though I think it's likely you're leaving a good deal of performance on the table). But I do think the former problem has little to do with generics as a language feature.

My goal was to explain how I make do with the features that exist (paying one of the tradeoffs, productivity, compile time, or runtime), and that any more general purpose implementation of generics would, to be orthogonal with existing features, necessarily slow compilation (because it would have to take over the job of slices and maps today, and would become prevalent in our APIs). I'm not trying to shift the argume…

> any more general purpose implementation of generics would, to be orthogonal with existing features, necessarily slow compilation (because it would have to take over the job of slices and maps today, and would become prevalent in our APIs).

It would not slow down compilation. Slices and maps are just built-in generics. Generics would codegen exactly the same way as slices and maps do now. Slices and maps compile down into calls to builtin runtime functions (using intensional type analysis IIRC); a generic version of them would, if implemented properly, call down into those exact same functions.

> There is a generics dilemma that programmers pay today and it should be possible to turn that into a language feature with the same tradeoffs.

Yes, it is possible and many languages have done it. All Golang needs to do is what Swift (just to name probably the closest analogue) does, with interfaces for runtime dispatch and generics for compile-time monomorphization. Or, if you want to continue using intensional type analysis to reduce compile time, implement that as certain variants of OCaml did (though you'll pay a performance cost to do so and I don't think it's worth it).

Re: Go 1.5 Release Notes

#60

Post by crawshaw »

pcwalton wrote: post #59
crawshaw wrote: post #55

Earlier quoted context omitted.

My goal was to explain how I make do with the features that exist (paying one of the tradeoffs, productivity, compile time, or runtime), and that any more general purpose implementation of generics would, to be orthogonal with existing features, necessarily slow compilation (because it would have to take over the job of slices and maps today, and would become prevalent in our APIs). I'm not trying to shift the argume…

> any more general purpose implementation of generics would, to be orthogonal with existing features, necessarily slow compilation (because it would have to take over the job of slices and maps today, and would become prevalent in our APIs). It would not slow down compilation. Slices and maps are just built-in generics. Generics would codegen exactly the same way as slices and maps do now. Slices and maps compile dow…

Compile-time specialization is exactly what would slow the compiler down too much. Doing it for slices and maps is already pushing it, doing it for more types (and judging by how generics is used in every other language, it would be a lot of types) would be a significant slowdown.

That said, your second point is good, my argument is weak because the compiler could stick to just specializing maps and slices and otherwise boxing. I strongly suspect any passable generics implementation for Go will need to do this (which due to necessary stdlib changes is off the table until Go 2, so understand I comment on this topic purely for the sake on conversation, I don't think anything can be done any time soon). The degree to which it needs to do it, I'm not sure.

There is still an orthogonality issue with interfaces. There's a lot of overlap between a dynamic dispatch mechanism and parametric polymorphism. As an API designer I'm a bit worried about it. I suspect if a good generics implementation came along though that argument would get pushed aside.

On this topic: one of the better prototypes I saw had a lot of trouble producing good error messages. I suspect this is a solvable problem, but how is not clear to me yet.

Also, we call it Go, not Golang.

Post reply on HN