
Go 1.2.1 is released - enneff
https://groups.google.com/forum/#!msg/golang-nuts/KLbkfDG5GgU/tcfb9ZYgttAJ
======
simonsarris
Do _any_ teams in Google write a human readable change log?

The only one I know of that comes close is the Chrome team, which gets by with
a blogspot[1] that sometimes has nice lists of the changes (sometimes in list
form, sometimes in a paragraph with loads o' commas), and sometimes says stuff
like:

> A partial list of changes in this build is available in the SVN revision log
> [http://build.chromium.org/f/chromium/perf/dashboard/ui/chang...](http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/branches/1750_132/src&range=253861:254028&mode=html)

And here with Go 1.2.1 we get this[2].

It's not a huge deal in this case, but if you release a version and link to it
and want us to know _why_ its significant, it would be nice to find out why in
English instead of SVN-ese.

Compare this to the great, readable version that Firefox offers[3]

~~~

[1]
[http://googlechromereleases.blogspot.com/](http://googlechromereleases.blogspot.com/)

[2] [https://code.google.com/p/go/source/list?name=release-
branch...](https://code.google.com/p/go/source/list?name=release-
branch.go1.2&r=7ada9e760ce34e78aee5b476c9621556d0fa5d31)

[3] [https://www.mozilla.org/en-
US/firefox/27.0.1/releasenotes/](https://www.mozilla.org/en-
US/firefox/27.0.1/releasenotes/)

~~~
enneff
Hey, so this would be my job, I guess.

The reason I don't bother writing a separate change log is that I'd end up
duplicating what the 5 changes on that page (above 1.2, the previous release)
already say. All are subtle things that are of little meaning to most people,
so I figure those that really care are going to read the changes anyway. Maybe
I should revisit this next minor release.

I should note that there is WAY more in that Firefox point release than in any
Go point release. We strictly include only critical fixes for issues for which
there is no workaround. For Go point releases, most people should just install
them and move on. For 99.9% of Go programmers there is "nothing to see here".

As has been already mentioned, we do provide a detailed change log for major
releases: [http://golang.org/doc/go1.2](http://golang.org/doc/go1.2)
[http://golang.org/doc/go1.1](http://golang.org/doc/go1.1)

~~~
simonsarris
I suppose that's a fair response, but at the risk of being rude please
consider some advice from a marketing perspective.

> All are subtle things that are of little meaning to most people...

If the changes do have little to no meaning in themselves, it's important to
consider: _Why did you submit it, and why does it sit at the top of HN?_

HN didn't upvote it because of the changelog itself. There's nothing there. HN
upvoted it because HN wants to know more about what's going on with Go.

So what's really happened, is that HN is affording you a great opportunity
here, but the contents of the post are sorta clutching defeat from the jaws of
victory. I think we could both agree that Go is a great language that we want
people to be excited about, and releases can make good front-of-mind
advertising at the very least.

If making the release announcements is part of your job then I think you
should take it on yourself to get the prospective audience excited. Tell us
everything that's happened since 1.2, including reminding us of any major
advances surrounding go. Here's what people want to hear:

 _The Go team is plugging along. Go is getting more dependable than ever. Here
's what we're doing with Go, by the way. Here's the latest projects. Here's
the latest tools._

Don't just say the changes since 1.2, tell us _everything in your ecosystem
that 's changed._

Teach us to long for the immensity of the sea, as it were[1].

[1]
[https://gist.github.com/simonsarris/9318374](https://gist.github.com/simonsarris/9318374)

~~~
enneff
My goal with the mailing list post and the submission was to let as many Go
users as possible that a new release is out and they should upgrade. Should I
use a minor release announcement as an occasion to get people more excited
about Go? I'm not sure. I like the short and sweet nature of these point
releases, and I'm wary of turning them into a marketing exercise.

Otherwise, I do spend a lot of time telling people what's going on with Go.
For instance, my presentation on what's new in Go 1.3 was at the top of HN for
a day.

Appreciate the feedback, though.

~~~
bsdetector
So how is this different from any other spammer? You're get paid to use Hacker
News as a Go mouthpiece to promote your product every chance you can take.

The reason why you, a Google employee working on Go, shouldn't be submitting
these stories is because you have a clear conflict of interest. You think that
5 changes totaling a few dozen lines of code is worth everybody's attention
because you're in the thick of it.

But really, a story like this being front page I think calls into question
whether there is a voting ring or voting bot; I can't imagine more than a
person or two actually looked at the changes and said this is important.

~~~
enneff
No need to be so cynical. You may not be interested in Go, but many
programmers are, and many of them read HN (and vote). You underestimate the
size and enthusiasm of the Go community.

~~~
endersshadow
Right, so please add some summary of changes/content to this. I don't have
time to go through SVN commit logs, but I'm interested in Go and use it in
some side projects. I want to quickly be able to say, "What changed? Can I
apply it to my projects?" Not having that is wildly frustrating when I see
these "version releases" where I have no clue what's worth my time.

------
ansimionescu
The message was posted 2 hours ago, and now I'm downloading go-1.2.1 after a
simple "brew update && brew upgrade". I love living in the future.

~~~
Dewie
_Meanwhile, in Ubuntu land..._

> This is to get into the next LTS version of Ubuntu,

~~~
StavrosK
Isn't there a PPA for this? I'm pretty sure I had one.

~~~
iends
The PPA is no longer maintained, instead the recommend solution is to use
godeb: [http://blog.labix.org/2013/06/15/in-flight-deb-packages-
of-g...](http://blog.labix.org/2013/06/15/in-flight-deb-packages-of-go)

~~~
StavrosK
Huh, that's interesting, thanks. I don't see why they don't set up a PPA
(since they already have a way to generate the debs), but I'm guessing there
are some issues with that.

------
turnip1979
I noticed that the minimum goroutine stack size was raised from 4KB to 8KB
between 1.1 and 1.2. Anyone know why this was increased?

~~~
enneff
The 8kb size was demonstrated to be optimal:

[https://codereview.appspot.com/14317043](https://codereview.appspot.com/14317043)

[http://swtch.com/~rsc/gostackamd64.html](http://swtch.com/~rsc/gostackamd64.html)

[http://swtch.com/~rsc/gostack386.html](http://swtch.com/~rsc/gostack386.html)

~~~
turnip1979
It is problematic if you want to have millions of tcp connections serviced
from the same host.

[https://groups.google.com/forum/#!topic/golang-
nuts/8cXGTWGU...](https://groups.google.com/forum/#!topic/golang-
nuts/8cXGTWGUzWw)

~~~
rdtsc
If you have to handle that many connections, I would suggest looking at
Erlang. Its default heap of a process is < 3K.

Usually that shouldn't matter as much as both have small process sizes
compared to OS threads or processes. But at millions of connections it starts
to matter. Whatsapp for example, was running on FreeBSD and Erlang with 2M+
connections.

~~~
ballard
Go needs optional arguments for goroutines and have global defaults because
recompiling is ludicrous.

Erlang is an ok language with a great runtime. Elixir is much higher level
language and hence more productive for teams that already know Erlang but want
to write less code and build faster. Also with Erlang, static type checking
not used much in Erlang and big loss unless you use dialyzer. Advantage go for
compiling and running test cases laser-blindingly fast. There is a native
QuickCheck framework for Erlang, and I'm sure someone wrote a go one.

~~~
enneff
Have you tried recompiling Go?

This is building the tool chain and standard library on my modest machine with
a cold cache:

    
    
        $ time ./make.bash
        real	0m42.763s
        user	1m11.655s
        sys	0m13.411s
    

Hardly a colossal burden.

~~~
ballard
I've run it a zillion times. That's not the point, and that doesn't solve the
problem. The point is per goroutine configurable stack sizes.

------
kelseyhightower
Thank you!

I'm really glad to see the Go team sticking with the short release cycles.
Very easy to follow what's changing and what to expect in the next release.

------
Zariel
This is to get into the next LTS version of Ubuntu, 1.3 is not far away
either.

------
brunoqc
Anyone else have the following error when trying to build stuff using the
64-bits version?

# flag C:\Go\src\pkg\flag\flag.go:87: undefined: strconv.ParseBool

------
sigzero
Wow! A point release! Can we just save "Go x.x.x is released" for major
releases?

------
pgstartup
very good

