Go 1.5 Beta
golang.org
golang.org
Work is ongoing to make golang.org be HTTPS only.
It seems to me like they've included Google's trace viewer[0] into the go tool, nice.
This seems quite a drastic change. I thought compilation speed was one of the pilars of go. In that light, why did they decide to release this anyway?
And it's not just the compiler, the linker didn't even know if a package is used or not, which is why you have to manually remove unused imports (otherwise they would be linked in, bloating the binary).
I need to point out that your second point about the linker is totally false. The linker knows and does drop unreferenced code. The import strictness is a language requirement and comes from experience with large codebases at Google and elsewhere. Use goimports in your editor's save hook and don't think about it.
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.
> 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.
http://www.chris-granger.com/2012/02/26/connecting-to-your-c...
http://www.objc.io/issues/16-swift/rapid-prototyping-in-swif...
Rapid prototyping doesn't work as well if you need wait for compilation.
JRebel exists for Java to improve redeployment times:
"By default, Go programs run with GOMAXPROCS set to the number of
cores available; in prior releases it defaulted to 1."
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?
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 lack of generics.
Much more likely is that some programs become slower due to the fact that GOMAXPROCS>1 requires more locks and atomic operations. That's not false sharing, though; that's just synchronization overhead.
I'm going to guess that you haven't played too much with executing things in parallel? In Clojure groups, people have heard beginners express surprise about parallel mode programs running slower so often, it's somewhat shaped the reaction to such questions.
few people use concurrent read-write data structures anyway (other than channels, of course)
One can still get in trouble with channels of pointers to structs.
Much more likely is that some programs become slower due to the fact that GOMAXPROCS>1 requires more locks and atomic operations. That's not false sharing,
Depending on how the locks and atomic operations are implemented and used, the slowdown with locks and atomic operations could be in large part because of false sharing. (I don't know the details for Go.)
False sharing is a very specific type of synchronization problem whereby data tightly packed in memory gets shared between multiple processors because the cache line size is larger than desired, even though logically the data in question are completely independent. This can happen, but it's nowhere near the most common type of synchronization-related performance problem in my experience. If your problem actually needs to share the data between multiple processors (e.g. with Go channels), then it's not "false" sharing anymore—it's "true" sharing.
pcwalton is one of the lead engineers of Servo, a Mozilla Research project to develop a more parallelizable browser engine in Rust. I'd say he's played around quite a bit with executing things in parallel!
Generics allow building reusable forms of complex data structures, reducing the cost in developer effort of each specialized use. By not supporting generics, Go increases the cost of each specialized use of complex data structures, which narrows the range of circumstances where the cost will be justified by the benefit.
Whether or not "the problem calls for it" is always a cost vs. benefit question, and Go -- compared to languages with support for generics -- increases the cost of this particular solution.
Notably, cgo is now supported on Solaris as of Go 1.5 beta.
The same should hold true of various OpenSolaris-based distributions such as Illumos, et al.
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.
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.
So, that more complex garbage collector is a product of that less-sexy rewrite.
Well we can toss out Go as a suitable language for real-time applications such as video games and audio processing.
I don't think the new GC precludes Go from being suitable for writing games. On the contrary, I think it is now more suitable, and look forward to using Go for writing games myself.
So I admire their goal to reduce latency (it's probably a latency-throuhput tradeoff) and I always get told that real-time (which in my opinion requires low-latency) is possible in GC-languages, I just do not know how to do that reliable. But I hope I am wrong and it is possible to go real-time with a GC as it is often a prerequisite for high-level language features.
This should be "96 bits".
I think it is mostly a getting started point, and not generally useful unless your only target is Linux (which very likely may be the case unless you're working on desktop apps).
I've been playing around with it, here's a neat example that does shared library partial bindings for http.Server in C and Python: https://github.com/shazow/gohttplib
I have not yet seen the "plugin" package in https://tip.golang.org/pkg/ as promised under the heading of "A new package" in the design doc.
1 - https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...