Go 1.5 Beta

http://golang.org/dl/

by azylman • 11 years ago

137 80 11 years ago

golang.org

crawshaw• 11 years ago

If you use Go and you can, please try it out and file bugs. http://golang.org/issue

vruiz7• 11 years ago

changelog: 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

ovis• 11 years ago

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

vruiz7• 11 years ago

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.

azylman2• 11 years ago

Performance is supposed to be much improved: https://docs.google.com/document/d/1At2Ls5_fhJQ59kDK2DFVhFu3...

vruiz7• 11 years ago

Obviously the new GC and GOMAXPROCS take the spotlight, I was just surprised about the new trace function.

melle• 11 years ago

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 drastic change. I thought compilation speed was one of the pilars of go. In that light, why did they decide to release this anyway?

vruiz7• 11 years ago

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

bsdetector• 11 years ago

Compilation speed was just a gimmick anyway; the compiler is fast because it doesn't do many expensive optimizations. It was like bragging that using "-O0" makes a compiler so fast. There are languages that require a lot of work just to compile at all, like C++, but for most languages slow compilation is more a measure of how advanced the compiler is.

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

JulianMorrison• 11 years ago

They are porting to self-hosted in Go only. And they are willing to trade off compilation speed, temporarily, for getting there at all. Machine translated code will be full of low hanging fruit to get the old speed back.

tomphoolery• 11 years ago

Thank you...this is what should have been posted in the original link.

ianchildress2• 11 years ago

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

azylman2• 11 years ago

We're pretty excited for the compiler and runtime being in Go, because we publish binaries for many different operating systems. Previously this required installing a separate cross-compilation toolchain, but will not any longer.

spenczar5• 11 years ago

Rewriting the compiler in Go was a precondition for improving garbage collection, according to Rob Pike. The old C codebase was complex and finicky, and, to an increasing extent, contributors to the Go language often know Go better than C.

So, that more complex garbage collector is a product of that less-sexy rewrite.

ianchildress2• 11 years ago

Great explanation, that explains a lot!

egor83• 11 years ago

Thread on mailing list:

http://thread.gmane.org/gmane.comp.lang.go.general/159797

tirus• 11 years ago

Has anyone spotted the documentation for the new shared library system yet? Plugin-based architecture is one of the biggest things I've wanted in Go and it seems to finally be happening.

shazow• 11 years ago

The closest thing to documentation is still the design document: https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...

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

dvirsky5• 11 years ago

Is it possible to dynamically load libraries that have been compiled with -buildmode=shared in runtime from within a running Go program? The design doc talked about it IIRC.

mitchellh• 11 years ago

I played around with this on my own, and the shared library system will only work with Linux binaries for now. I wasn't able to get it working with OS X or Windows, with the very clear message from Go telling me the "platform target is not supported."

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

zzzcpan2• 11 years ago

Wrong binaries in go1.5beta1.linux-386.tar.gz, don't work on linux 386. Looks like they are for amd64.

enneff4• 11 years ago

Thanks for the report. We're using a new tool to roll the release binaries, and you have discovered a bug. On it.

enneff4• 11 years ago

It's now updated. Please download the new file (sha1 70112cca6a7225bacac4a32ffab2d97bcd7613f4) and confirm that it works for you.

cyber1• 11 years ago

go1.5beta1.darwin-amd64.tar.gz don't work on mac os x 10.10

enneff4• 11 years ago

It works on my 10.10 machine. Can you please file an issue?

https://golang.org/issue/new

sebcat• 11 years ago

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.

habosa• 11 years ago

I'm excited to see experimental support for vendoring. One nice thing about go is that the dependency management is part of the core language design, but it always fell flat when you needed specific versions of a library. Vendoring solves that huge issue, I hope it works as nicely as they claim.

binarycrusader• 11 years ago

Of particular note, Solaris support in Go 1.5 is greatly improved thanks to the work of Aram Hăvărneanu; Oracle sponsored most of that work.

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.

bradfitz3• 11 years ago

Please file bugs to add anything missing from the release notes.

4ad• 11 years ago

You welcome. Mdb, DTrace, and SPARC64 support coming soon too...

EarlPoncho2• 11 years ago

is this worth learning

bradfitz3• 11 years ago

Yes.

mansilladev• 11 years ago

http://javascriptissexy.com/understand-javascripts-this-with...

EarlPoncho2• 11 years ago

what does this have to do with go

tyho5• 11 years ago

Can anybody clarify what is meant by " Generate machine descriptions from PDFs (or maybe XML).", " "Read in PDF, write out an assembler configuration"."? That sounds . . . ambitious.

https://talks.golang.org/2015/gogo.slide#22

gcatlin• 11 years ago

Rob Pike talks about it here: https://youtu.be/cF1zJYkBW4A?t=29m6s

mseepgood• 11 years ago

Here's an example: https://github.com/rsc/x86/blob/master/x86.csv#L37

schmichael• 11 years ago

Really wish these HN links to download pages were HTTPS. Lots of people at Gophercon on untrustworthy conference wifi that probably wouldn't notice a MITM'd download page pointing to non-HTTPS binary downloads.

dsymonds• 11 years ago

Yep, the link should be https://golang.org/dl/.

Work is ongoing to make golang.org be HTTPS only.

AndyKelley• 11 years ago

The "stop the world" phase of the collector will almost always be under 10 milliseconds and usually much less.

Well we can toss out Go as a suitable language for real-time applications such as video games and audio processing.

fgaaldal2• 11 years ago

Why the down-votes, I think this is a valid point. In case of real-time, e.g. video games, you want to render every ~15ms and doing that with a GC is really NOT trivial. I do not say, GC-languages perform bad, they actually are great for throughput, but doing low-latency stuff is still hard.

enneff4• 11 years ago

The new GC reduces pauses to the single-digit milliseconds. Rendering every ~15ms seems reasonable under those constraints. Plus I don't think a game engine will typically put a lot of pressure on the garbage collector.

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.

Merkur• 11 years ago

cool Release! i realy like the all the improvements in tooling. thx!

sdevlin• 11 years ago

Also in the crypto/cipher package, there is now support for nonce lengths other than 96 bytes in AES's Galois/Counter mode (GCM), which some protocols require.

This should be "96 bits".

Go 1.5 Beta

Related Stories