8 ms·

Go 1.2.1 is released

135 points by enneff 13y ago

simonsarris 13y ago
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/changelog.html?url=/branches/1750_132/src&range=253861:254028&mode=html http://build.chromium.org/f/chromium/perf/dashboard/ui/chang... 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.go1.2&r=7ada9e760ce34e78aee5b476c9621556d0fa5d31 https://code.google.com/p/go/source/list?name=release-branch... [3] https://www.mozilla.org/en-US/firefox/27.0.1/releasenotes/ https://www.mozilla.org/en-US/firefox/27.0.1/releasenotes/
- elithrar 13y ago
  Go's major releases typically get a human readable changelog: http://golang.org/doc/go1.2 http://golang.org/doc/go1.2 - but yes, something for the point releases would be nice but probably not worth the time.
- enneff 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        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.
turnip1979 13y ago
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 13y ago
  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 13y ago
    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/8cXGTWGUzWw https://groups.google.com/forum/#!topic/golang-nuts/8cXGTWGU...
    - f2f 13y ago
      too bad, it can't be changed now. that would require editing a number and recompiling!
    - turnip1979 13y ago
      Can't reply to the f2f's snarky comment. I'm not saying I don't know how to change the value. I want to understand why the designers made the decision to do so.
      - 4ad 13y ago
        Then read the three links pointing above?
        turnip1979 13y ago
        All I see are a few perf graphs that show a 20% runtime reduction in a few cases and > 50% reduction in one case. This gives me no insight whatsoever what is going on under the hood. Is it that for these dozen or so benchmarks, we end up using > 4K and < 8K of heap? So the extra 20% time is just going into a memory allocation? P.S. Interesting that I got two snarky comments asking for a basic question about Go. Does not bode well.
pgstartup 13y ago
very good
ansimionescu 13y ago
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 13y ago
  Meanwhile, in Ubuntu land... > This is to get into the next LTS version of Ubuntu,
  - StavrosK 13y ago
    Isn't there a PPA for this? I'm pretty sure I had one.
    - iends 13y ago
      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-go http://blog.labix.org/2013/06/15/in-flight-deb-packages-of-g...
      - StavrosK 13y ago
        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.
- jvehent 13y ago
  Happy rollback when it breaks ;)
Zariel 13y ago
This is to get into the next LTS version of Ubuntu, 1.3 is not far away either.
kelseyhightower 13y ago
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.
sigzero 13y ago
Wow! A point release! Can we just save "Go x.x.x is released" for major releases?
brunoqc 13y ago
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

135 points by enneff 13y ago

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/changelog.html?url=/branches/1750_132/src&range=253861:254028&mode=html http://build.chromium.org/f/chromium/perf/dashboard/ui/chang... 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.go1.2&r=7ada9e760ce34e78aee5b476c9621556d0fa5d31 https://code.google.com/p/go/source/list?name=release-branch... [3] https://www.mozilla.org/en-US/firefox/27.0.1/releasenotes/ https://www.mozilla.org/en-US/firefox/27.0.1/releasenotes/

elithrar 13y ago
Go's major releases typically get a human readable changelog: http://golang.org/doc/go1.2 http://golang.org/doc/go1.2 - but yes, something for the point releases would be nice but probably not worth the time.
enneff 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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.

turnip1979 13y ago

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 13y ago
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 13y ago
  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/8cXGTWGUzWw https://groups.google.com/forum/#!topic/golang-nuts/8cXGTWGU...
  - f2f 13y ago
    too bad, it can't be changed now. that would require editing a number and recompiling!
  - turnip1979 13y ago
    Can't reply to the f2f's snarky comment. I'm not saying I don't know how to change the value. I want to understand why the designers made the decision to do so.
    - 4ad 13y ago
      Then read the three links pointing above?
      - turnip1979 13y ago
        All I see are a few perf graphs that show a 20% runtime reduction in a few cases and > 50% reduction in one case. This gives me no insight whatsoever what is going on under the hood. Is it that for these dozen or so benchmarks, we end up using > 4K and < 8K of heap? So the extra 20% time is just going into a memory allocation? P.S. Interesting that I got two snarky comments asking for a basic question about Go. Does not bode well.

pgstartup 13y ago

very good

ansimionescu 13y ago

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 13y ago
Meanwhile, in Ubuntu land... > This is to get into the next LTS version of Ubuntu,
- StavrosK 13y ago
  Isn't there a PPA for this? I'm pretty sure I had one.
  - iends 13y ago
    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-go http://blog.labix.org/2013/06/15/in-flight-deb-packages-of-g...
    - StavrosK 13y ago
      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.
jvehent 13y ago
Happy rollback when it breaks ;)

Zariel 13y ago

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

kelseyhightower 13y ago

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.

sigzero 13y ago

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

brunoqc 13y ago

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