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:
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]
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".
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].
I love the way the Go team operates, including the way the point releases are handled. The last thing this the world needs is more marketing bullshit- No nonsense, just like Go: Go by engineers for engineers. Go will do fine "marketing" itself on its merits and the merits of things created with it.
>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.
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!
+1 to short and sweet incremental change lists. VLC / Firefox used to be this way until /someone/ deemed those not worthy. You can still get to the VLC changes which ware way more satisfying to read:
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.
Anecdote: I have a general interest in the progress of Go, even though I don't program in it. I clicked through, saw no real content, and moved on to the comments to see if they would talk about what changed. I'm not going to try to parse svn commits - such things are written for people who know the code.
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.
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.
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.
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.
As someone interested in Go, I looked at it because it was worth a look...
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.
See there you go. There's absolutely nothing in these 5 bug fixes of note, but I should be tempted to have a look at the language because of them? This story is just a shameless hackvertisement for Go.
> 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?
I explain it being it on the front page due to lots of people being interested in Go.
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.
So in other words you are saying that people here will vote up any story about Go regardless of merit; seeing "Go" in the title makes it interesting to them.
What is it about this story of a point release with five inconsequential bug fixes that is at all interesting?
You may as well ask what's interesting about the latest IOS point release, what's interesting about the latest nginx release, what's interesting about the latest Haskell / Erlang / Dart / Oberon / Clojure release.
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.
>> You may as well ask what's interesting about the latest IOS point release, what's interesting about the latest nginx release, what's interesting about the latest Haskell / Erlang / Dart / Oberon / Clojure release.
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.
For what it's worth, I'm happy to see the Go update announcement here. I only hack occasionally on Go so I haven't updated it in a while, but seeing this post has prompted me to download the latest version.
If you teach them to long for the immensity of the sea, as it were, won't they get frustrated by building the boat and start to take dangerous short cuts so they can get out to sea, or maybe even ride whales and drown? It may also serve the purpose of marketing to keep things boring.
"plugging away" sounds scary by the way. It could imply they are thoughtless.
An automated process to take https://code.google.com/p/go/source/list?name=release-branch... and output it into a textual list that has the full title of the bug fix would be a huge improvement. There's a lot of noise in that table, along with some things being cut off even on my desktop monitor (to say nothing of when I was trying to read it on my phone this morning), and it's hard to skim visually for interesting things.
> 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".
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.
It seems contradictory in this case, but not when you consider all the previous releases.
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.
Go's major releases typically get a human readable changelog: http://golang.org/doc/go1.2 - but yes, something for the point releases would be nice but probably not worth the time.
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.
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.
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.
My understanding is the second page of that 8 KB is allocated in a virtual memory sense, not a physical one. As the stack grows once it is larger than 4 KB there will be a page fault and the 2nd page will become backed. So the memory situation should be no worse then before this change was made...
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.
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.
How much minimum overhead (kernel and userland) per socket is there with a single process watching as many sockets as reliable via select/epoll/kqueue? Say a setup in C for simplicity's sake. Would be an interesting experiment.
While I do opt for better performance, this change particularly was a bit shocking to me, as in reality it broke the compatibility promise. Sure your stuff will compile fine, but it also meant things that worked fine before now died. I'm not ultimately against the change, but just feel other changes that were more deserving were rejected on grounds this one indirectly violated...
No, everything that worked before, still does (on 64-bit). A stack segment uses 8kB of virtual address space. It will only use a page (4kB) of physical memory if you don't need that much stack. The operating system will map the second page only when it faults.
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'll refrain from making a smartass comment, just state I understand the difference perfectly. This causes a jump in physical memory usage. See reply to your parent.
Interesting. Definitely important when I get around to finishing a mosquitto (mqtt) client/server framework. For anyone that isn't familiar, mqtt is used on a massive scale for telemetry data and log shipping. This makes it great for IM (Facebook msgr uses it IIRC).
How is any of that relevant? The discussion is about carrier grade messaging maximizing connection density per server, not connecting a watch to a pair of sunglasses.
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/