Go 1.2.1 is released
groups.google.com
groups.google.com
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...
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/
[2] https://code.google.com/p/go/source/list?name=release-branch...
[3] https://www.mozilla.org/en-US/firefox/27.0.1/releasenotes/
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.1
> 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].
>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.
gag
You realize golang.org isn't a startup right? :)-
If this is what you are looking for check this out: http://www.golangweekly.com/archive/ (or if you want smaller bites the mailing list https://groups.google.com/forum/#!forum/golang-nuts)
>don't just say the changes since 1.2, tell us everything in your ecosystem that's changed.
This is a tiny maintenance change, I don't want to read a fricking newsletter. Of course maybe I'm wrong- maybe- CVEs, and issues filed need more marketing speak too! After all, they might get linked on Hacker News! What an opportunity!
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.
These updates are a fantastic opportunity to talk about interesting technical points. What changed and why? You don't need to think about it as marketing, just an excuse for some quick-n-dirty tech talk.
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.
I don't expect every HN post to be "important" as that differs from reader to reader. The fact that this ended up on the front page, and doesn't contain much easily consumable information for anyone not interested in Go, should possibly tempt you to have a look at the language, instead of assuming voting rings or bots.
I personally have minimal interest in many topics that get covered on HN. I usually just don't click on them, but if they get enough coverage I'll usually check the topic out to see if my preconceptions were flawed.
> instead of assuming voting rings or bots.
I've several times in the past seen new stories critical of Go on reddit go from 1 to -20 in less than a minute. This stopped about when uriel died so I just assumed it was him, but maybe it's still going on HN. How do you explain this post being on the front page?
The same way I explain posts related to startups, open source, patent law, Bitcoin (MtGox being the current star), the NSA etc.
People are interested in different things, and HN is full of an incredibly disparate range of people. No need to assume foul play for this story, unless you'd also like to assume the same for the other categories listed above.
What is it about this story of a point release with five inconsequential bug fixes that is at all interesting?
As I said previously, people are interested in different things. I don't see the point in expending emotion and energy getting angry about the fact that a couple of lines of text on an ephemeral web-site weren't the couple of lines of text you would have preferred to see... Do you get equally offended when the HTTP spec is discussed on HN? Or when you hear of new Kickstarter campaign on HN? or hundreds of other sub-topics which people happen to be interested in.
My reason for checking out the release notes was to see if there were any security issues that may have effected my code, and to see if there were any updates on new features etc. And no, I didn't up-vote the story at all, I just read it.
Yes, exactly so! You should ask that question. That's the question I'm asking, and not getting an answer to. The latest iOS release fixed a massive security flaw in TLS/SSL.
This Go release? According to the guy who released it, contains minor bug fixes they had been sitting on for 3 months and decided to make a point release just because it had been a while. A total non-story.
>> I don't see the point in expending emotion and energy getting angry
The name I chose is "bsdetector" and you're asking me why I would get upset at bullshit such as this Go story.
"plugging away" sounds scary by the way. It could imply they are thoughtless.
Isn't that a little contradictory? You are saying all the changes in this release are critical, yet there is "nothing to see here". As I understand it, these changes are critical corner cases but you believe that they are not experienced by 99.9% of the users.
However, you should consider two things:
1. Such critical issues might be useful information for users who are not facing those issue currently (but might hit them in the future).
2. Your estimation of 99.9% might be wrong, because not all users might have complained loudly or even realized that there is an issue.
With previous releases there has been what I call a "point-release-triggering fix". That is, a fix that simply cannot wait until the next release (for example, one that fixes a security hole). In those cases there is some advisory warning in the announcement. In this case, it had been 3 months since the last release and a few point-release-worthy (but not point-release-triggering) fixes had accumulated, so we though it's probably worth getting them out there before 1.3 (in another 3 months' time).
I have considered your points. That's why (in response to point 1) I have linked to the changes directly from the release announcement and acknowledged in my message that perhaps I should write the changes up in future, and (in response to point 2) I issued the point release in the first place and submitted the announcement post here so that Go users would know to upgrade.
To quote T. B. Lance 'if it ain't broke don't fix it'
That's really correct I bet. I scanned the changes for stuff I'm interested in, got what I needed. Back to work and thanks Go team for your work.
> This is to get into the next LTS version of Ubuntu,
https://codereview.appspot.com/14317043
https://groups.google.com/forum/#!topic/golang-nuts/8cXGTWGU...
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.
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.
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
The guy having issues in that thread was trying to handle major load with a machine with < 8 GB of memory. All my production boxes have 128-256 GB... I had some 16 and 32 GB for a long time with no issues.
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.
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.
stack, not heap. We are talking about changing the default stack size.
>So the extra 20% time is just going into a memory allocation?
Yes and the book keeping overhead involved at the OS and runtime levels.
If you need more stack, the point is moot because you used more physical memory before as well, it was just split into more stack segments.
I've used mqtt for a project in the past. It worked really well but I didn't have very high messaging load for that application.
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.
# flag C:\Go\src\pkg\flag\flag.go:87: undefined: strconv.ParseBool