
Go 1.5 Beta - azylman
http://golang.org/dl/
======
schmichael
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
Yep, the link should be [https://golang.org/dl/](https://golang.org/dl/).

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

------
vruiz
changelog:
[https://tip.golang.org/doc/go1.5](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](https://github.com/google/trace-
viewer)

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

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

~~~
tyho
This is plain wrong, the main reason the compiler is fast according to the
authors[1] is because it handles dependencies more sanely than C/C++.

[https://talks.golang.org/2012/splash.article](https://talks.golang.org/2012/splash.article)

~~~
codemac
You're more than welcome to write C in the fashion that the go compiler
enforces, and get much faster builds. Their compiler is young and immature
relative to things like GCC and stating that it may be missing expensive
optimization features is not "plain wrong".

~~~
tyho
That suggestion is not really practical as you need to make the same
requirement from all your third party libraries. While gcc will spend more
time optimizing than go, the main reason for the speed difference at the
moment IS unnecessary work done by the preprocessor because of the primitive
importing.

~~~
pcwalton
No, it's not, unless you count time spent compiling inlined functions and
templates as "preprocessing time" (which it isn't—it's compilation time). Time
the difference between clang++ on -O0 versus -O3 if you don't believe me.

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

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

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

------
crawshaw
If you use Go and you can, please try it out and file bugs.
[http://golang.org/issue](http://golang.org/issue)

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

------
ianchildress
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._

~~~
spenczar5
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.

~~~
ianchildress
Great explanation, that explains a lot!

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

~~~
fgaaldal
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.

~~~
enneff
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.

~~~
fgaaldal
It is funny that just after I wrote this, I spotted another article on the
frontpage:
[https://sourcegraph.com/blog/live/gophercon2015/123574706480](https://sourcegraph.com/blog/live/gophercon2015/123574706480)

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.

~~~
0xdeadbeefbabe
ISTR that producing a clean sign wave on a scope requires a real-time
operating system, and it was one of the first tests for seeing if your real
time linux patches worked.

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

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

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

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

~~~
zzzcpan
It works now. Thanks. Even tried cross-compilation, works too.

------
tirus
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
The closest thing to documentation is still the design document:
[https://docs.google.com/document/d/1nr-
TQHw_er6GOQRsF6T43GGh...](https://docs.google.com/document/d/1nr-
TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/view)

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](https://github.com/shazow/gohttplib)

~~~
dvirsky
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.

~~~
kodablah
According to the release notes [1], "For the amd64 architecture only, the
compiler has a new option, -dynlink, that assists dynamic linking by
supporting references to Go symbols defined in external shared
libraries."...so I assume if you want all of your Go signatures visible in
your shared Go libraries, you can do it on x64. I have not tested this myself.

1 -
[https://tip.golang.org/doc/go1.5#compiler](https://tip.golang.org/doc/go1.5#compiler)

~~~
dvirsky
the question though is how do you go about actually loading it? can it be done
without patching the runtime, or without running some C based "bridge" that
loads the shared object file? I'm talking about a plugin architecture, say,
where I want to load an implementor of an interface from a .so file, etc.

~~~
kodablah
Based on a cursory overview of the design document, this appears to be done by
not putting all of the Go signatures in the library (e.g. ELF headers
somewhere) but instead based on a hash. From the design document [1]: "The
shared library should include a hash of the export data for each package that
it contains. It should also include a hash of the export data for each shared
library that it imports. These hashes can be used to determine when packages
must be recompiled. These hashes should be accessible to any build tool, not
just the go tool." To me this is basically saying that so long as the hashes
of the .so file match your binary, your dynamic load should be able to trust
the uses of the same interface known at compile time.

I have not yet seen the "plugin" package in
[https://tip.golang.org/pkg/](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...](https://docs.google.com/document/d/1nr-
TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/view)

~~~
dvirsky
But I'm wondering - will this mysterious "plugin" package require changes in
Go's core runtime, or can I implement whatever functionality it will expose
right now. It looks to me like it can't be done without some C bridge/glue
while not changing Go itself.

~~~
ianlancetaylor
The mysterious "plugin" package does not yet exist, and won't be in the 1.5
release. I would encourage you to try to implement it and send in the changes.
The ideas in the execution modes doc are being steadily filled in by people
who need them.

~~~
dvirsky
Do you have any pointers as to where do I start? I mean I can see how I can
probably do it with a C bridge, but I don't know the runtime well enough to
attempt to do it without it. Glad it's written in Go now :)

------
tyho
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](https://talks.golang.org/2015/gogo.slide#22)

~~~
mseepgood
Here's an example:
[https://github.com/rsc/x86/blob/master/x86.csv#L37](https://github.com/rsc/x86/blob/master/x86.csv#L37)

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

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

[https://golang.org/issue/new](https://golang.org/issue/new)

------
egor83
Thread on mailing list:

[http://thread.gmane.org/gmane.comp.lang.go.general/159797](http://thread.gmane.org/gmane.comp.lang.go.general/159797)

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

------
EarlPoncho
is this worth learning

~~~
mansilladev
[http://javascriptissexy.com/understand-javascripts-this-
with...](http://javascriptissexy.com/understand-javascripts-this-with-clarity-
and-master-it/)

~~~
EarlPoncho
what does this have to do with go

