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

21–30 of 66 posts

Re: Go 1.5 Release Notes

#21

Post by masklinn »

cpeterso wrote: post #19

> In Go 1.5, the order in which goroutines are scheduled has been changed. The properties of the scheduler were never defined by the language, but programs that depended on the scheduling order may be broken by this change. Are there any more details about the change to goroutine scheduling? Is this more than the just change to the GOMAXPROCS' default value?

> Are there any more details about the change to goroutine scheduling?

That would defeat the repetition about scheduling order being undefined wouldn't it?

But according to issue 11372 the answer is that up to 1.4 the scheduler would run goroutines in definition order so if you started goroutines 1,2,3,4,5 it tended to run 1,2,3,4,5. In 1.5 it's biased to favour the last-started routine so it'd run 5,1,2,3,4. Again scheduling order is undefined so the order may change again in 1.6, explicitly relying on it would be an idiotic idea.

They have also introduced limited scheduling randomisation in race detection mode[0] which they intend to randomise further in 1.6 to make scheduling-order dependencies easier to suss out and fix.

> Is this more than the just change to the GOMAXPROCS' default value?

The change to GOMAXPROCS wouldn't have changed the order in which the scheduler picks routines, since it could already be set to a non-default value previously.

[0] https://github.com/golang/go/commit/202807789946a8f3f415bf00...

Re: Go 1.5 Release Notes

#22

Post by snuxoll »

arihant wrote: post #12

tl;dr - No change in language, one minor consistency oversight fixed. Big changes on implementation, including compiler being bootstrapped.

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

Re: Go 1.5 Release Notes

#23

Post by arihant »

snuxoll wrote: post #22
arihant wrote: post #12

tl;dr - No change in language, one minor consistency oversight fixed. Big changes on implementation, including compiler being bootstrapped.

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

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 accepted. Besides, Go's primary design principle is that of composability. So you're using reflection in one form or another. Achieving generic behaviour with interface and reflection is much more consistent than generics as we know from other languages.

Re: Go 1.5 Release Notes

#24

Post by gillianseed »

chimeracoder wrote: post #10
hencq wrote: post #7

The release notes mention the new Go compiler is about 2x slower than the old C based one. It also mentions there's ongoing work to improve this. I wonder if there are any estimates on how close to the original performance they think they can get. Do they expect to reach parity by, say, 1.6 or will it always be slower? For my tiny hobby projects, compile times aren't an issue at all so I'm asking purely out of curios…

> I wonder if there are any estimates on how close to the original performance they think they can get. Do they expect to reach parity by, say, 1.6 or will it always be slower? I imagine that's just a side-effect of rewriting the entire compiler; I'd expect the next versions to improve on the speed. Though in the meantime, if compilation time is an issue, you can always try gccgo. On my larger projects, it's slightly…

What's the performance in gccgo nowadays, back when I tried it certain things was slightly faster but a lot was slower compared to the official compiler.

I read that it mainly had to do with lack of escape analysis, has this changed in recent gcco releases ?

Re: Go 1.5 Release Notes

#25

Post by EFruit »

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 employ plugins written in Go, but Go can not.

Re: Go 1.5 Release Notes

#26

Post by aikah »

snuxoll wrote: post #22
arihant wrote: post #12

tl;dr - No change in language, one minor consistency oversight fixed. Big changes on implementation, including compiler being bootstrapped.

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 the variable type T is required and insert type assertions for the user. Been thinking about that.

Re: Go 1.5 Release Notes

#28

Post by bsaul »

arihant wrote: post #23
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 -_-

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…

Purely out of curiosity, do you know of any talk that would explain in detail why things like swift's protocol extension can be implemented in conjunction with generics, and go interfaces can't ?

From the outside, the two features (swift's protocol with extensions and go interfaces) seem a bit close, so that made me wonder. I didn't have the time to think too much in detail about it, so i'm just wondering if anybody already had.

Re: Go 1.5 Release Notes

#29

Post by pcwalton »

bsaul wrote: post #28
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…

Purely out of curiosity, do you know of any talk that would explain in detail why things like swift's protocol extension can be implemented in conjunction with generics, and go interfaces can't ? From the outside, the two features (swift's protocol with extensions and go interfaces) seem a bit close, so that made me wonder. I didn't have the time to think too much in detail about it, so i'm just wondering if anybody…

You certainly can implement Go-like interfaces alongside generics. There's nothing inconsistent about them.

Re: Go 1.5 Release Notes

#30

Post by coldtea »

_ph_ wrote: post #14
hencq wrote: post #7

The release notes mention the new Go compiler is about 2x slower than the old C based one. It also mentions there's ongoing work to improve this. I wonder if there are any estimates on how close to the original performance they think they can get. Do they expect to reach parity by, say, 1.6 or will it always be slower? For my tiny hobby projects, compile times aren't an issue at all so I'm asking purely out of curios…

They automatically translated C code to Go code. The objective was to produce correct Go code, speed was not an immediate concern - the auto-translated code mostly is very bad Go code, speed wise. Optimizing the Go code base of the compiler is the next step, planned to happen in subsequent releases.

>the auto-translated code mostly is very bad Go code, speed wise.

Is it? It might not be particularly optimized, but why would that ("very bad speed wise") be the case?

Post reply on HN