Go 1.5 Beta
golang.org
Go 1.5 Beta
1–10 of 82 posts
Re: Go 1.5 Beta
#2If you use Go and you can, please try it out and file bugs. http://golang.org/issue
Re: Go 1.5 Beta
#3changelog: https://tip.golang.org/doc/go1.5
It seems to me like they've included Google's trace viewer[0] into the go tool, nice.
Re: Go 1.5 Beta
#4changelog: https://tip.golang.org/doc/go1.5 It seems to me like they've included Google's trace viewer[0] into the go tool, nice. [0] https://github.com/google/trace-viewer
"By default, Go programs run with GOMAXPROCS set to the number of
cores available; in prior releases it defaulted to 1."
Re: Go 1.5 Beta
#5These are pretty big to me:
The garbage collector is now concurrent and provides dramatically lower pause times by running, when possible, in parallel with other goroutines.
By default, Go programs run with GOMAXPROCS set to the number of cores available; in prior releases it defaulted to 1.
But how important is this? It doesn't seem like it affects the average user:
The compiler and runtime are now written entirely in Go (with a little assembler). C is no longer involved in the implementation, and so the C compiler that was once necessary for building the distribution is gone.
Re: Go 1.5 Beta
#6changelog: https://tip.golang.org/doc/go1.5 It seems to me like they've included Google's trace viewer[0] into the go tool, nice. [0] https://github.com/google/trace-viewer
"By default, Go programs run with GOMAXPROCS set to the number of cores available; in prior releases it defaulted to 1." This is exciting, but what are the implications? I remember something once about some 3rd-party code, and maybe even some stdlib code behaving poorly on multiple processors.
With the new scheduler I believe this is much less of an issue. It is huge though because there might be a bunch of data races in the wild that were hidden until now and are about to see the light of day. Hopefully most people test with -race these days.
Re: Go 1.5 Beta
#7Thread on mailing list:
Re: Go 1.5 Beta
#8changelog: https://tip.golang.org/doc/go1.5 It seems to me like they've included Google's trace viewer[0] into the go tool, nice. [0] https://github.com/google/trace-viewer
Obviously the new GC and GOMAXPROCS take the spotlight, I was just surprised about the new trace function.
Re: Go 1.5 Beta
#9Earlier quoted context omitted.
"By default, Go programs run with GOMAXPROCS set to the number of cores available; in prior releases it defaulted to 1." This is exciting, but what are the implications? I remember something once about some 3rd-party code, and maybe even some stdlib code behaving poorly on multiple processors.
With the new scheduler I believe this is much less of an issue. It is huge though because there might be a bunch of data races in the wild that were hidden until now and are about to see the light of day. Hopefully most people test with -race these days.
For high concurrency systems, I'd expect false sharing to start rearing its ugly head.
I only recently got knocked over the head with -race by the oh-so-diplomatic folks on IRC. It's very good. Might as well use it -- otherwise it's like driving with a broken check engine light.
Speaking of false sharing, would it be a good idea to take the Go implementation of Disruptor and use that for buffered channels?
Re: Go 1.5 Beta
#10changelog: https://tip.golang.org/doc/go1.5 It seems to me like they've included Google's trace viewer[0] into the go tool, nice. [0] https://github.com/google/trace-viewer
"By default, Go programs run with GOMAXPROCS set to the number of cores available; in prior releases it defaulted to 1." This is exciting, but what are the implications? I remember something once about some 3rd-party code, and maybe even some stdlib code behaving poorly on multiple processors.
Performance is supposed to be much improved: https://docs.google.com/document/d/1At2Ls5_fhJQ59kDK2DFVhFu3...