7 ms·

Go 1.5 Release Notes

123 points by raingrove 11y ago

frou_dh 11y ago
Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree?
- odonnellryan 11y ago
  I think it is more dogfooding, no? Or proof of concept/completeness?
  - fatihpense 11y ago
    I agree. Also another benefit is that people interested in Go and not in C can now contribute to compiler itself.
- matthewbauer 11y ago
  More I think that most compilers want to be written in the language that they compile. Go has been moving toward this for a while since the compiler rewrite in Go. It's hard to call yourself a C successor when your compiler depends on a C compiler.
- chimeracoder 11y ago
  > Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree? Go is quite literally written by the people who invented C, wrote C, and made it what it is today. (Ken Thompson wrote one of the first commits to the language). The reason for purging C from the Go toolchain is that it makes it harder for Go developers to contribute. Go developers already all know Go (by definition) - why make them use a language that they may not know as well in order to contribute back to the project? Furthermore, mixing C code with Go code can cause performance issues if not done right. While you can expect the official project to "do it right", this still raises the bar for people who know Go and want to contribute, but don't know C as well. And frankly, I don't think it's that significant to say that they don't want to write C anymore. C was a great language for its time, and it still is a great language in many ways. But it's almost half a century old; it would be more surprising if after almost 50 years they couldn't write a language that they prefer even more!
  - ori_b 11y ago
    > Furthermore, mixing C code with Go code can cause performance issues if not done right. While you can expect the official project to "do it right", this still raises the bar for people who know Go and want to contribute, but don't know C as well. This is why Go was maintaining it's own C compiler -- They had it modified to work well with Go, as far as I am aware[1]. Removing it means one less compiler to maintain. [1] From Go 1.4, the source for the Go C compiler: https://github.com/golang/go/tree/883bc6ed0ea815293fe6309d66f967ea60630e87/src/cmd/6c https://github.com/golang/go/tree/883bc6ed0ea815293fe6309d66...
- vezzy-fnord 11y ago
  Bell Labs alums have never had a specific penchant for C, per se, though their languages have mostly had C-like ALGOL syntax.
- digikata 11y ago
  I don't have the link handy right now, but IIRC there was a mention of some system level differences in how Go might like to change things in the toolchain under the language level which could move in a fundamentally different direction from the C toolchain. An example was in the area of how stacks were created and operated. I think one could foresee making more changes in the future in that area. It's sort of exciting to think that these fairly low level foundational details which much of programming relies on, could be rethought and maybe get us to a different place than we are now.
- tagrun 11y ago
  https://talks.golang.org/2015/gogo.slide#4 https://talks.golang.org/2015/gogo.slide#4
ValentineC 11y ago
Here's the Go 1.5 release schedule: https://groups.google.com/forum/#!topic/golang-nuts/hm9tWv534bI https://groups.google.com/forum/#!topic/golang-nuts/hm9tWv53... The final version should be released in mid-August.
hencq 11y ago
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 curiosity.
- chimeracoder 11y ago
  > 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 faster than gc 1.5. YMMV, obviously.
  - gillianseed 11y ago
    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 ?
  - Zariel 11y ago
    The new compiler is now garbage collected, and is generating lots of garbage, when the old compiler ran without any garbage collection. There is an interesting thread from the mailing list about this [0] [0] https://groups.google.com/d/topic/golang-dev/6obxRcm-rqc/discussion https://groups.google.com/d/topic/golang-dev/6obxRcm-rqc/dis...
- deleted 11y ago
  [deleted]
- _ph_ 11y ago
  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.
ecliptik 11y ago
Good to momentum is still growing with the arm64 port, I remember a year ago it was looking like it may never happen. https://twitter.com/maver/status/496376555237806080 https://twitter.com/maver/status/496376555237806080 but in Feb the story changed and with this release it's well on it's way to a full port. https://twitter.com/davecheney/status/567621293109821440 https://twitter.com/davecheney/status/567621293109821440
- koffiezet 11y ago
  And by the time it's stable, it will be useless for official iOS development, since Apple will require developers to submit apps in LLVM bytecode (they nicknamed it "Bitcode"). For Apple Watch apps, this is already mandatory. For Apple this makes sense if they want to switch architectures or add additional extensions to their CPU's and not require all developers to re-submit their apps, but it sucks a bit for the darwin/arm64 port of Go. Maybe we'll see an LLVM bytecode target in a few years? Then Go applications could also benefit from LLVM optimizations.
arihant 11y ago
tl;dr - No change in language, one minor consistency oversight fixed. Big changes on implementation, including compiler being bootstrapped.
- snuxoll 11y ago
  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 -_-
  - arihant 11y ago
    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.
    - bsaul 11y ago
      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.
      - pcwalton 11y ago
        You certainly can implement Go-like interfaces alongside generics. There's nothing inconsistent about them.
0xdeadbeefbabe 11y ago
Anyone know how to cross compile with cgo?
- arat 11y ago
  https://github.com/davecheney/golang-crosscompile https://github.com/davecheney/golang-crosscompile
- grey-area 11y ago
  In go 1.4, you need to build the go tools for a given target beforehand. In go 1.5, you'll only have to set some environment variables before you call go build, that's it, but unfortunately this doesn't include cgo: env GOOS=linux GOARCH=arm GOARM=7 go build hello.go This link is a good summary of the situation now and in future: http://dave.cheney.net/2015/03/03/cross-compilation-just-got-a-whole-lot-better-in-go-1-5 http://dave.cheney.net/2015/03/03/cross-compilation-just-got... This one talks about cgo: https://medium.com/@rakyll/go-1-5-cross-compilation-488092ba44ec https://medium.com/@rakyll/go-1-5-cross-compilation-488092ba...
cpeterso 11y ago
> 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?
- masklinn 11y ago
  > 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/202807789946a8f3f415bf00007ee100cf3ec710 https://github.com/golang/go/commit/202807789946a8f3f415bf00...
EFruit 11y ago
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.
- NateDad 11y ago
  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.
bribri 11y ago
Still no generics
dadrian 11y ago
They're defaulting away from SSLv3, nice!
NateDad 11y ago
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.
- millstone 11y ago
  No, there are many more potential issues with GCs beyond this one metric.
- flohofwoe 11y ago
  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...".
  - NateDad 11y ago
    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.
  - Gepsens 11y ago
    Did you read ? With 1 Gig of Heap that's less than 1ms, and if you're creating a UI or a gaming engine there are ways to recycle objects in order to prevent GCs from working on useless object groups
- pcwalton 11y ago
  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.)
anh79 11y ago
Mine "go" experience comes with the latest docker 1.7. Ok okay. it comsumes 37% of 512 MB memory. That's fine. I will shutdown all of my apps for you. :P

123 points by raingrove 11y ago

frou_dh 11y ago

Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree?

odonnellryan 11y ago
I think it is more dogfooding, no? Or proof of concept/completeness?
- fatihpense 11y ago
  I agree. Also another benefit is that people interested in Go and not in C can now contribute to compiler itself.
matthewbauer 11y ago
More I think that most compilers want to be written in the language that they compile. Go has been moving toward this for a while since the compiler rewrite in Go. It's hard to call yourself a C successor when your compiler depends on a C compiler.
chimeracoder 11y ago
> Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree? Go is quite literally written by the people who invented C, wrote C, and made it what it is today. (Ken Thompson wrote one of the first commits to the language). The reason for purging C from the Go toolchain is that it makes it harder for Go developers to contribute. Go developers already all know Go (by definition) - why make them use a language that they may not know as well in order to contribute back to the project? Furthermore, mixing C code with Go code can cause performance issues if not done right. While you can expect the official project to "do it right", this still raises the bar for people who know Go and want to contribute, but don't know C as well. And frankly, I don't think it's that significant to say that they don't want to write C anymore. C was a great language for its time, and it still is a great language in many ways. But it's almost half a century old; it would be more surprising if after almost 50 years they couldn't write a language that they prefer even more!
- ori_b 11y ago
  > Furthermore, mixing C code with Go code can cause performance issues if not done right. While you can expect the official project to "do it right", this still raises the bar for people who know Go and want to contribute, but don't know C as well. This is why Go was maintaining it's own C compiler -- They had it modified to work well with Go, as far as I am aware[1]. Removing it means one less compiler to maintain. [1] From Go 1.4, the source for the Go C compiler: https://github.com/golang/go/tree/883bc6ed0ea815293fe6309d66f967ea60630e87/src/cmd/6c https://github.com/golang/go/tree/883bc6ed0ea815293fe6309d66...
vezzy-fnord 11y ago
Bell Labs alums have never had a specific penchant for C, per se, though their languages have mostly had C-like ALGOL syntax.
digikata 11y ago
I don't have the link handy right now, but IIRC there was a mention of some system level differences in how Go might like to change things in the toolchain under the language level which could move in a fundamentally different direction from the C toolchain. An example was in the area of how stacks were created and operated. I think one could foresee making more changes in the future in that area. It's sort of exciting to think that these fairly low level foundational details which much of programming relies on, could be rethought and maybe get us to a different place than we are now.
tagrun 11y ago
https://talks.golang.org/2015/gogo.slide#4 https://talks.golang.org/2015/gogo.slide#4

ValentineC 11y ago

Here's the Go 1.5 release schedule: https://groups.google.com/forum/#!topic/golang-nuts/hm9tWv534bI https://groups.google.com/forum/#!topic/golang-nuts/hm9tWv53... The final version should be released in mid-August.

hencq 11y ago

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

chimeracoder 11y ago
> 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 faster than gc 1.5. YMMV, obviously.
- gillianseed 11y ago
  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 ?
- Zariel 11y ago
  The new compiler is now garbage collected, and is generating lots of garbage, when the old compiler ran without any garbage collection. There is an interesting thread from the mailing list about this [0] [0] https://groups.google.com/d/topic/golang-dev/6obxRcm-rqc/discussion https://groups.google.com/d/topic/golang-dev/6obxRcm-rqc/dis...
deleted 11y ago
[deleted]
_ph_ 11y ago
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.

ecliptik 11y ago

Good to momentum is still growing with the arm64 port, I remember a year ago it was looking like it may never happen. https://twitter.com/maver/status/496376555237806080 https://twitter.com/maver/status/496376555237806080 but in Feb the story changed and with this release it's well on it's way to a full port. https://twitter.com/davecheney/status/567621293109821440 https://twitter.com/davecheney/status/567621293109821440

koffiezet 11y ago
And by the time it's stable, it will be useless for official iOS development, since Apple will require developers to submit apps in LLVM bytecode (they nicknamed it "Bitcode"). For Apple Watch apps, this is already mandatory. For Apple this makes sense if they want to switch architectures or add additional extensions to their CPU's and not require all developers to re-submit their apps, but it sucks a bit for the darwin/arm64 port of Go. Maybe we'll see an LLVM bytecode target in a few years? Then Go applications could also benefit from LLVM optimizations.

arihant 11y ago

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

snuxoll 11y ago
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 -_-
- arihant 11y ago
  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.
  - bsaul 11y ago
    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.
    - pcwalton 11y ago
      You certainly can implement Go-like interfaces alongside generics. There's nothing inconsistent about them.

0xdeadbeefbabe 11y ago

Anyone know how to cross compile with cgo?

arat 11y ago
https://github.com/davecheney/golang-crosscompile https://github.com/davecheney/golang-crosscompile
grey-area 11y ago
In go 1.4, you need to build the go tools for a given target beforehand. In go 1.5, you'll only have to set some environment variables before you call go build, that's it, but unfortunately this doesn't include cgo: env GOOS=linux GOARCH=arm GOARM=7 go build hello.go This link is a good summary of the situation now and in future: http://dave.cheney.net/2015/03/03/cross-compilation-just-got-a-whole-lot-better-in-go-1-5 http://dave.cheney.net/2015/03/03/cross-compilation-just-got... This one talks about cgo: https://medium.com/@rakyll/go-1-5-cross-compilation-488092ba44ec https://medium.com/@rakyll/go-1-5-cross-compilation-488092ba...

cpeterso 11y ago

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

masklinn 11y ago
> 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/202807789946a8f3f415bf00007ee100cf3ec710 https://github.com/golang/go/commit/202807789946a8f3f415bf00...

EFruit 11y ago

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.

NateDad 11y ago
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.

bribri 11y ago

Still no generics

dadrian 11y ago

They're defaulting away from SSLv3, nice!

NateDad 11y ago

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.

millstone 11y ago
No, there are many more potential issues with GCs beyond this one metric.
flohofwoe 11y ago
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...".
- NateDad 11y ago
  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.
- Gepsens 11y ago
  Did you read ? With 1 Gig of Heap that's less than 1ms, and if you're creating a UI or a gaming engine there are ways to recycle objects in order to prevent GCs from working on useless object groups
pcwalton 11y ago
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.)

anh79 11y ago

Mine "go" experience comes with the latest docker 1.7. Ok okay. it comsumes 37% of 512 MB memory. That's fine. I will shutdown all of my apps for you. :P