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

41–50 of 66 posts

Re: Go 1.5 Release Notes

#41

Post by skybrian »

coldtea wrote: post #32
arihant wrote: post #23

Earlier quoted context omitted.

Russ Cox said this year that generics aren't left out because of political reasons or design choice. They are left out because of technical constraints which are: - Generics in current form won't work across the board with all parts of Go. - Generics of form that will work for Go across the board are not technically trivial. Honestly, I appreciate Go's philosophy of not implementing until fully understood and accepte…

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

Re: Go 1.5 Release Notes

#42

Post by ninkendo »

aikah wrote: post #26
snuxoll wrote: post #22

Earlier quoted context omitted.

And still no generics. Honestly, at this point I just wish they'd add a 'void' alias for 'interface {}' so at least non-typesafe code was only as ugly as the equivalent C -_-

AFAIK you can create a named type from interface{} type V interface{} Don't hold your breath when it comes to generics. There is no way they can retrofit them without breaking the language, it's too late. Even features like covariance or unions are just out of question. An option would be to write a super-set of Go with generics that would compile to Go code. what it would do basically is use interface{} everywhere t…

> An option would be to write a super-set of Go with generics that would compile to Go code.

You could call it go++!

(But seriously, that's pretty much what C++ did to C.)

Re: Go 1.5 Release Notes

#43

Post by sirseal »

pcwalton wrote: post #38
crawshaw wrote: post #36

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

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

This is a fantastic explanation. Thank you for phrasing it so concisely.

Re: Go 1.5 Release Notes

#44

Post by NateDad »

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.

Re: Go 1.5 Release Notes

#45

Post by NateDad »

EFruit wrote: post #25

Back when the dynamic linking design doc was published, it included support for a 'plugin' build mode, wherein the package was compiled into a .so and a 'plugin' package to load and access said shared objects. Having written a number of things that would have been greatly simplified by having such a facility, I'm sad to see it didn't make the cut and has been all but forgotten. It annoys me greatly to see that C can…

I don't believe it's been forgotten, they just ran out of time. There aren't infinite code monkeys working on this thing. AFAIK, almost all of the dynamic linking stuff is being done by one guy - Michael Hudson (a fellow Canonicaler who we're paying to help out with the Go toolchain).

Projects slip, especially ones like this which are fairly large and complex. I want Go plugins, too... but it takes time, and shared libraries were higher priority. Once the bugs are shaken out of shared libraries, plugins become a pretty logical (and hopefully small) next step.

Re: Go 1.5 Release Notes

#46

Post by millstone »

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.

No, there are many more potential issues with GCs beyond this one metric.

Re: Go 1.5 Release Notes

#47

Post by threeseed »

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…

If Go's overriding focus is speed then why have a garbage collector ? Or write the compiler in Go ?

Or do you think that just maybe using speed as a reason not to do something is a bit of a cop out. Especially without any benchmarks to back it up.

Re: Go 1.5 Release Notes

#48

Post by flohofwoe »

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 software") is a garbage collector that allows full control over when and how long it triggers. This sentence from the release notes "The 'stop the world' phase of the collector will almost always be under 10 milliseconds and usually much less." is completely meaningless in this regard, it basically still says "time required for garbage collection can be anything, sometimes less then 10ms, sometimes more, who knows...".

Re: Go 1.5 Release Notes

#49

Post by crawshaw »

pcwalton wrote: post #38
crawshaw wrote: post #36

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

> 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 builtin slice and map types almost always meet my needs. For the long tail of parameterized types in that power distribution, it appears that either it is not a performance hot spot, in which case I can borrow from the dynamic dispatch tools in the language (that is, some variant of an interface{}), or performance is so critical that even in C++ there is no obvious generic data type.

The latter is an interesting case I ran into in my prior life as a C++ programmer, and in OCaml. Someone had created a generic version of a data structure (usually more than one someone), but what I needed in my performance hot spot was some variant that wasn't captured by the parameterization.

An old example that comes to mind: I inherited a struct whose memory layout described a wire protocol. It had an 8-byte piece of padding in the middle of it. That was the perfect place to hide the pointer for a linked list I wanted to create in an intermediate step. Of course, none of the many template-based linked list data structures I had in C++ could do that, so I rolled my own.

So as unexpected as this may be, I find a combination of map/slice, interface{}, and rolling my own meets my generics needs in Go well enough that I wouldn't want to trade off slower compilation for it, or bad compile-time error messages. I still miss generics, and it may be that the particular kinds of programming I do mean I miss them less than others. A co-worker with nearly as much Go experience as I have says he misses them more often. The ones that come up most often for me are sorting and some kind of ordered map, but even those bug me less than once a month.

Re: Go 1.5 Release Notes

#50

Post by crawshaw »

threeseed wrote: post #47
crawshaw wrote: post #36

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

If Go's overriding focus is speed then why have a garbage collector ? Or write the compiler in Go ? Or do you think that just maybe using speed as a reason not to do something is a bit of a cop out. Especially without any benchmarks to back it up.

There seem to be a few points in your comment, let me try to answer them as best I can:

The Go 1.5 compiler is not slower because it is written in Go, it is slower because it was mechanically translated from another language. Human eyes will improve it over time.

Garbage collection is a throughput hit the language designers (and I) are willing to accept for improved safety and simpler APIs. I'd rather not pay it, but I choose it over spending a large chunk of my API documentation describing various ownership scenarios like I did in C++. It's a tradeoff I find acceptable for most programs. You won't find me using a GC on a clock slower than 100 MHz, or in a sub-millisecond realtime system (but I probably won't be using linux either there).

I'm also willing to pay the performance hit on non-critical generic code, and I use interface{} for that where I can. If benchmarks show it's a problem, I'll do something differently. That might be hand-rolling an algorithm, which is unfortunate for the programmer who follows me and has to read it. But it doesn't come up much.

The performance price for generating large amounts of extra code in the compiler is reasonably well understood, and not something that would be amenable to simply trying and benchmarking. One would have to implement generics, then spend several programmer-years tuning the compiler over various programs, compilers are complex machines.

Again, I haven't met a compiler expert who doesn't think that generating code for widely used generics would be expensive. And they would be widely used, any good generics solution would have to replace maps and slices, and would permeate the standard library.

Post reply on HN