Wrong binaries in go1.5beta1.linux-386.tar.gz, don't work on linux 386. Looks like they are for amd64.
Go 1.5 Beta
21–30 of 82 posts
Re: Go 1.5 Beta
#22Earlier quoted context omitted.
From the changelog: > Builds in Go 1.5 will be slower by a factor of about two. The automatic translation of the compiler and linker from C to Go resulted in unidiomatic Go code that performs poorly compared to well-written Go. Analysis tools and refactoring helped to improve the code, but much remains to be done. Further profiling and optimization will continue in Go 1.6 and future releases. This seems quite a drast…
2x is still means much faster than C++. Go has an strict release cycle[0] and at some point you have to make the switch if you want a compiler easier to develop. I'm sure it'll get much better soon. https://github.com/golang/go/wiki/Go-Release-Cycle
Fast builds is definitely a major feature. Go has attracted more Python developers than C++ developers.
http://commandcenter.blogspot.it/2012/06/less-is-exponential...
Go is great as a much faster Python, where speed matters. If Go compiles slow too much, it becomes less attractive.
Re: Go 1.5 Beta
#23go1.5beta1.darwin-amd64.tar.gz don't work on mac os x 10.10
Re: Go 1.5 Beta
#24Earlier quoted context omitted.
2x is still means much faster than C++. Go has an strict release cycle[0] and at some point you have to make the switch if you want a compiler easier to develop. I'm sure it'll get much better soon. https://github.com/golang/go/wiki/Go-Release-Cycle
Fast builds is definitely a major feature. Go has attracted more Python developers than C++ developers. http://commandcenter.blogspot.it/2012/06/less-is-exponential... Go is great as a much faster Python, where speed matters. If Go compiles slow too much, it becomes less attractive.
The compilation time is slower, not the resulting compiled binary.
> On average the programs in the Go 1 benchmark suite run a few percent faster in Go 1.5 than they did in Go 1.4, while as mentioned above the garbage collector's pauses are dramatically shorter, and almost always under 10 milliseconds.
Re: Go 1.5 Beta
#25Earlier quoted context omitted.
Fast builds is definitely a major feature. Go has attracted more Python developers than C++ developers. http://commandcenter.blogspot.it/2012/06/less-is-exponential... Go is great as a much faster Python, where speed matters. If Go compiles slow too much, it becomes less attractive.
The compilation time is slower, not the resulting compiled binary. > On average the programs in the Go 1 benchmark suite run a few percent faster in Go 1.5 than they did in Go 1.4, while as mentioned above the garbage collector's pauses are dramatically shorter, and almost always under 10 milliseconds.
I'm referring to compilation speed. In Python and Ruby, for example, there is no compile stage. This makes them attractive for rapid iteration.
Re: Go 1.5 Beta
#26> The DNS resolver in the net package has almost always used cgo to access the system interface. A change in Go 1.5 means that on most Unix systems DNS resolution will no longer require cgo, which simplifies execution on those platforms.
This is great news if you're on one of those systems supporting it, using the net module and don't like the libc dependency, or if you're doing a lot of concurrent DNS requests.
Re: Go 1.5 Beta
#27go1.5beta1.darwin-amd64.tar.gz don't work on mac os x 10.10
It works on my 10.10 machine. Can you please file an issue?
Re: Go 1.5 Beta
#28Earlier quoted context omitted.
The compilation time is slower, not the resulting compiled binary. > On average the programs in the Go 1 benchmark suite run a few percent faster in Go 1.5 than they did in Go 1.4, while as mentioned above the garbage collector's pauses are dramatically shorter, and almost always under 10 milliseconds.
I'm referring to compilation speed. In Python and Ruby, for example, there is no compile stage. This makes them attractive for rapid iteration.
Meh, most people will never notice it, and if for someone is an issue, you can continue to develop using 1.4 locally until 1.6 comes in 6 months.
Re: Go 1.5 Beta
#29changelog: 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
Thank you...this is what should have been posted in the original link.
Re: Go 1.5 Beta
#30Earlier quoted context omitted.
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?
> For high concurrency systems, I'd expect false sharing to start rearing its ugly head. I'd be really surprised if that results in programs in parallel mode becoming slower than sequential (which is what you get with GOMAXPROCS=1). Cache effects are important, but not that important in a setting like Go, where few people use concurrent read-write data structures anyway (other than channels, of course) due to the lac…
What does lack of generics have to do with concurrent vs non-concurrent data structures? It seems like if the problem calls for it, concurrent data structures would be used regardless of generics.