
Go 1.5 is released - rsc
https://blog.golang.org/go1.5
======
vessenes
Congrats, this is a huge release.

We had some weird corruption of memory issues late in the 1.5RC cycle.

It's possible that
[https://github.com/golang/go/commit/3ae17043f7f29f0d745aa35b...](https://github.com/golang/go/commit/3ae17043f7f29f0d745aa35b340f8cab80219068)
fixed it, but each test for bisection cost us 4 hours, and the bug didn't
always show. (When it did show, it definitely showed without -race mode on,
contrary to the comments in the patch)

Anyway, if you have a large memory usage highly concurrent go app, I would
still tread lightly and carefully with this release; we spent a goodly amount
of time blaming our own code before realizing that 1.4.2 did not exhibit the
problem.

~~~
rsc
To be fair, this is true of pretty much any major release of a new piece of
software: tread lightly and test carefully before deploying to production.

The new GC, default GOMAXPROCS > 1, and changes to the scheduler may well
expose latent bugs in code that worked fine in Go 1.4.

~~~
vessenes
Totally. We've been mostly running tip for some time, and sending in bug
reports when we can be useful, overall a big win for us, but not without its
risks. :)

Honestly, I could have seen rebranding 1.5 to 2.0; there are major under the
hood changes you guys have made.

~~~
rsc
I can see that, and I've been idly wondering over the past few days what the
largest N will be for Go 1.N. The contrast with most version numbering,
however, is that we've defined a meaning for Go 2: it breaks all your Go 1
programs. Being a Go 1.X release is actually a stronger statement about how
your code will behave.

~~~
andrewchambers
Waiting for the confusion when Go1 2.0 is released :). Or are you thinking of
1.10?

~~~
tagrun
"Go1 2.0" is meaningless, Go X refers to Go X.Y.Z. Many FOSS programs treat X,
Y and Z as numbers rather than digits, and increment X when there is a
breaking change in the API or some serious restructuring/change (this is
starting to change, recently we see programs incrementing major version
periodically [most remarkably, Linux, Firefox, GCC have jumped on this
bandwagon], these days only FOSS libraries are seriously sticking to that.) so
yeah, it's probably going to be 1.10 and so on.

------
travjones
>"The compiler tool chain was translated from C to Go, removing the last
vestiges of C code from the Go code base."

This is really cool. Writing a compiler in the language that you're compiling
seems kind of meta. The language has evolved to a point to where it can
consume and build itself. Far out mannnnn.

Thanks Go team!

~~~
mrdrozdov
Perhaps this is a dumb question, but what language was used to compile the
compiler? Was it compiled in C? Surely it must have had to of been compiled in
a different language somewhere down the chain.

~~~
crawshaw
It is built with Go 1.4. Details:
[https://golang.org/s/go15bootstrap](https://golang.org/s/go15bootstrap)

------
gnufrra
I am glad there is now support for vendor directories, albeit experimental at
this stage.

[https://go-review.googlesource.com/#/c/10923/](https://go-
review.googlesource.com/#/c/10923/)

Go 1.5 vendor proposal:

If there is a source directory d/vendor, then, when compiling a source file
within the subtree rooted at d, import "p" is interpreted as import
"d/vendor/p" if that exists.

When there are multiple possible resolutions, the most specific (longest) path
wins.

The short form must always be used: no import path can contain “/vendor/”
explicitly.

Import comments are ignored in vendored packages.

~~~
mfer
We were excited enough we pivoted glide, the package manager, to directly
support this new vendor setup.

Anyone interested can learn more at
[https://github.com/Masterminds/glide](https://github.com/Masterminds/glide)
or where I posted about it at
[http://engineeredweb.com/blog/2015/glide-0.5-go-vendor-
suppo...](http://engineeredweb.com/blog/2015/glide-0.5-go-vendor-support/).

I'm hopeful for this brave new vendor world.

------
rcarmo
If you use ARM devices, it might be worth pointing out that Dave Cheney has
unofficial tarballs of _older_ versions here:

[http://dave.cheney.net/unofficial-arm-
tarballs](http://dave.cheney.net/unofficial-arm-tarballs)

No 1.5 (yet), but if, like me, you do ARM stuff, you might want to bookmark
this.

And of course the cross-compiler works, but still.

(edit: moved mention of ARM to first line)

------
hit8run
Congratulations on the 1.5 release. I already updated my dev machine and
everything looks to be still running without errors. Soon my servers will get
updates, too!

PS: If you want to benefit from 1.5 improvements don't forget to recompile
your go programs ;)

~~~
andrewstuart2
And you can recompile in shared object mode if you want tiny programs and
shared linking too, though you'll lose the benefit of the single static
binary.

    
    
        go install -buildmode=shared std
        go build -linkshared

------
mattetti
We updated Splice's CI to 1.5 and rolled out our code to prod. The total GC
pause time improvement is quite drastic for us:
[https://twitter.com/mattetti/status/634114976362291200](https://twitter.com/mattetti/status/634114976362291200)

Throughput hasn't changed and average performance is about the same for us
(slightly faster actually)

~~~
shizcakes
Same here!
[https://twitter.com/brianhatfield/status/634166123605331968](https://twitter.com/brianhatfield/status/634166123605331968)

------
kodablah
So, who's gonna be the first to blog about compiling a Go lib as c-shared
dynamic lib and call it from Rust for serious HN karma? Seriously though,
there are several well-written Go libraries for accessing systems that I
wonder if the runtime isn't too much baggage to keep the shared libs from
being used outside of Go.

------
coldcode
Still no real debugger?

~~~
icedchai
printf isn't good enough for you?

~~~
vvanders
This attitude is so toxic, it's like saying isn't assembler good enough for
you?

Good tools matter, there's nothing more painful then a platform where your
only debugging is printf.

~~~
fredkbloggs
> This attitude is so toxic, it's like saying isn't assembler good enough for
> you?

Real programmers don't need an assembler; ed(1) is sufficient and if you can't
write a program without anything else, you shouldn't be allowed near
computers.

~~~
amyjess
The story of Mel: [http://www.catb.org/jargon/html/story-of-
mel.html](http://www.catb.org/jargon/html/story-of-mel.html)

------
omginternets
I'm continually surprised at how fast the Go team works.

------
anonfunction
Happy to see Travis-CI updated gimme[1] with 1.5 support just now!

I've been anticipating the change and had already updated my .travis.yml file
in my stats package[2] which would fall back to tip.

[1] [https://github.com/travis-ci/gimme/issues/19](https://github.com/travis-
ci/gimme/issues/19)

[2]
[https://github.com/montanaflynn/stats](https://github.com/montanaflynn/stats)

------
fitzwatermellow
Kudos to the Golang team and its many contributors. The reduction in latency
with concurrent GC is a massive step forward. I wouldn't be surprised to see
Golang gain significant traction in the research and HPC communities in the
near future.

Also glad to see wide adoption in Chinese consumer internet running at
gargantuan scale: Tencent, WeChat, Didi Kuaidi and many more. Are you guys at
all surprised to see it take off on the mainland?

------
SarahofGaia
I'm still a beginner with code. I've been learning HTML (not yet CSS, as far
as I know) and Markdown, and I'm also in the middle of learning Python using
free courses on Udacity. This is all in my free time. No courses taken. Would
this be a good language to learn right now, or would I be better off waiting
till I'm more experienced?

------
aikah
What's the state of dynamic linking in go? even with C libs , is it supported
? if yes does it work on Windows ? thx.

~~~
Merovius
It is supported. So you can both compile your go packages as a shared object
file and link against it and you can compile it into a shared library and load
it from C.

I have no idea about windows support.

~~~
irq-1
Very little of what was planned was implemented in 1.5. See the design doc:
[https://golang.org/s/execmodes](https://golang.org/s/execmodes)

edited summary:

\- Go code linked into, and called from, a non-Go program

In the Go 1.5 release this mode is implemented, using a .a file, for most Unix
systems.

\- Go code as a shared library plugin with a C style API

In the Go 1.5 release this mode is implemented for linux-amd64, linux-arm,
darwin-amd64, and darwin-arm. When using gccgo it is implemented for any
supported target.

\- Go code as a shared library plugin with a Go style API

This is not implemented in the Go 1.5 release.

\- Go code that uses a shared library plugin

This is not implemented in the Go 1.5 release.

\- Building Go packages as a shared library

In the Go 1.5 release this is implemented for the linux-amd64 target only.
When using gccgo it is implemented for any supported target.

\- A Go program built as a PIE

This is not implemented in the Go 1.5 release.

------
stock_toaster
Sounds like netgo is the default now? That is great -- no more having to
remind people to use `-tags netgo`!

------
inlined
I'm very excited to see Go supported as a library for server and client
development on iOS and Android. Are there any good case studies of app
developers using Go as a full-stack language?

~~~
cartoonfoxes
> Are there any good case studies of app developers using Go as a full-stack
> language?

It's been done, but the best use I'm aware of is under NDA.

------
0xdeadbeefbabe
Was it a joke when one of the core team guys said that he was looking forward
to seeing the go compiler in the go standard library?

Is the compiler go gettable?

~~~
rsc
No, it's not. I don't believe there are any plans to put it into the standard
library either. It's a standard tool, not a library.

------
ericfrederich
lol... Just built 1.4.2 (or whatever latest 1.4 was) last night. I was
wondering whether or not to go against master. I wonder if there were even any
commits since then or just a tag.

------
ecigjuice
Wow still no generics even after so many people asking for them

------
tmaly
cool, looking forward to testing it out.

------
tomp
Still no user-definable generics? ;)

~~~
andrewchambers
Trolling is a art.

~~~
tomp
Actually it's a sincere criticism.

~~~
andrewchambers
We all know that generics are not coming any time soon. The debate is over, it
isn't sincere.

~~~
tomp
That doesn't change the fact that the lack of user-defined generics is a valid
(and sincere) criticism.

