Hacker News Reader

Comment by skriticos2 | Hacker News Reader

So what I take from this is that the previous implementation sustained a huge amount of code rot and new code got layered over it with a staple instead of proper re factoring.

So he put the whole mess in a bin and re-done it cleanly with Go. Now it's much nicer. Some of Go's attributes helped along the way.

Did I miss something?

View on HN

I guess, what you miss is that the author was the author of LiveJournal, memcached, now also of groupcache in Go. So the guy who rewrote the program was much, much more capable that any "typical" programmer.

Your comment implies that even Google, which has a reputation of hiring only the best of the best software developers, has "typical" programmers. My faith in the world has just been restored, <3.

Best of the best that apply to Google. Or in other words, their hiring process is "Hire the best people that apply here", or, you know, the hiring policy of every company in the world. You could argue they uniquely attract smart people with some kind of high IQ gravity centered at the Googleplex, but that seems unlikely. Makes for good marketing copy though.

The degree to which it is enforced today - I'm not sure, but:

http://googleresearch.blogspot.com/2006/03/hiring-lake-wobeg...

Right, because there's never been a Googler who has ever made a mistake. All of them are perfect and none of them are stupid, never a bad hire made or even a momentary lapse of judgment.

What relevance does that add to this presentation? It's interesting by itself.

What do the presentation (or our discussion) gain from the fact that Brad is a super smart guy "much more capable than the 'typical' programmer"? Why are we even bringing up that point? :)

It adds some validity to the opinions and points he makes? I will certainly pay more attention to a presentation if I know that the presenter has credibility..

A bunch of "typical" programmers wrote a program in C++, and it turned out crappy. A "super smart guy" rewrote it in Go, and it turned out nice. How much of the delta between crappy and nice was due to the language, and how much to the programmer? (And how much is due to the new programmer learning from the old programmer's mistakes?)

As with all anecdotal language advocacy, you have to take it with a grain of salt, and in this case maybe more than usual.

Brad even acknowledges that the original program was nice in it's day. C++ complicated things but it sounded like the bigger problem was developers leaving the team and new features being hackishly implemented.

And don't underestimate "changing environment". As Brad said, "in 2007, using local disk wasn't restricted ... in 2012, containers get tiny % of local disk spindle time ... cluster file systems own disk time on your machine, not you."

Within Google today, if you're directly using local disk instead of the Google storage stack, you're going to have a bad time. Even more so if you're calling read() from a single-threaded event loop.

It gives the fuller perspective. The Go libraries are something very new. People who developed the libraries know them inside out. Outside of that group of people, there's certainly much less knowledge about them. A lot of the claims in the article about the full coverage of some standard in some Go library versus the incomplete one by the given C++ program obviously come from somebody who invested enough time to study the standards and (at least) study the implementation inside of the said libraries. That is, something like that either you know or you can just say authors claim that they adhere to the standards -- which ones, how much; you can't know, much less you are able to compare.

So, for me, that is somebody who didn't follow the state of Go libraries, it was much bigger new information in the presentation the author's certitude that some library covers everything of the standard (good to know how much care was invested there!) than the fact that when somebody has already made some very good tools he can more easily use them then probably anybody else who'd start without such a deep knowledge.

My own takeaway was "now that I know that at least some libraries are very well thought-out that's a good argument to consider when deciding about the use of Go in some future project." Still it's to weight against the learning curve and the quality and ease of use of the available libraries in other more common languages. In that light it's still good to know that the author of the presentation is really very competent.

Not directly related to your question, I also applaud the author's honesty in describing the problem he solved: first, the underlying assumptions changed: I can imagine that the main reason for fetching the data to the local disk in 2007 was that then fetching the data directly from the remote storage was much slower than it is now, making his current approach impossible then. Second, it's not that the original design was as inefficient as the later suboptimal modifications made it. Third, it was a project in which for a while nobody wanted to invest the time to. That's the convenient point to jump in and demonstrate what you can do with the new tools and your knowledge and time. Once you change the equation, a product once almost without the future can become a basis for future much more successful projects.

    > The Go libraries are something very new. People who    
    > developed the libraries know them inside out. Outside of 
    > that group of people, there's certainly much less 
    > knowledge about them.

I guess it's a tautology that the people who developed something know it best, but you're being really disingenuous here by implying that only those people would be capable of doing a project like this. Go's stdlib HTTP server takes great pains to be accessible and powerful.

I think the implication was that the developers know the actual capabilities, and so know if there were any dark corners of the standards that were just papered over with stuff that might break in some subtle way, in non obvious use-cases.

So it's a word of confidence that, yes not only is the interface nice, but the implementation is also good (enough) -- and you probably won't regret leaning on it in a future project.

If I'm correct he's a C programmer, not a C++ programmer.

Yes, they usually do better than "C++" programmers on C++

They know how to keep things simple

That kind of comment is uncalled for (I'm a C++ programmer).

Yes. In my opinion the biggest win comes from goroutines and Go's runtime, which essentially allow you to write asynchronous non-blocking multi-threaded(!)code that looks like synchronous code and is as easy to read and reason about. This leads to a huge reduction in complexity compared to the callback spaghetti you often get in other async frameworks. Basically putting concurrency first in the language and not relying on libraries seems to really pay off.

Thanks for the thorough yet concise explanation.

You don't have to build goroutines into the language to have lightweight multithreaded tasks. TBB does this for C++, for example. (Edit: I was mistaken about Java here -- apparently it does use OS threads.)

goroutines are lighter than Java threads, though, so it's still an improvement.

Lightweight Threads, Channels and Actors for the JVM: http://blog.paralleluniverse.co/post/49445260575/quasar-puls...

If you want to show that the JVM can do that, a better link is probably Akka: http://akka.io/ Your link appears to be a guy's personal project, which is great, but akka is from what I gather an industrial-strength implementation.

Though as the Node people occasionally point out, it is advantageous to have this sort of thing baked into the language, so that everything done in the language supports the concepts, rather than having a relatively small corner support it. Plus you get Go, instead of Java, which I for one would find an improvement.

Actually if one wants to use Akka, one should be using Scala. Akka using Java is a total pain in comparison. Atleast with Scala, one seldom gets the feeling that the library is far from the language semantics.

This is not true, regarding Java.

The Java language specification does not require the use of OS threads for Java threads.

It all depends which JVM you refer to.

The JVMs that make use of green threads follow a similar threading model to Go.

Don't mix languages with implementations.

C# 5 also has this, with the async/await keywords. The nice thing is that it works with older plain Task-based code (which was callback spaghetti).

Tasks are still OS threads, though they get lumped into a threadpool so a lot of the overhead is mitigated (in most cases).

The async/await model does not create new threads.

http://msdn.microsoft.com/en-us/library/vstudio/hh191443.asp...

TPL(Task parallel library) does use additional threads, and that's a different programming model.

The async/await model in C# is essentially from F#'s async workflows:

http://msdn.microsoft.com/en-us/library/dd233250.aspx

I realize that, what I was referring to was the old model (TPL), which wasn't terrible to begin with.

The "new" model is just syntactic sugar over the "old" TPL, so you're wrong anyway ;-)

Yep, I feel that the main point of the story is "we had crappy code, and rewrote it and now it's great".

Could have been very similar if they'd rewritten it using C++11 features (the main difference being that you'd have to use a HTTP library instead of HTTP being in the standard library, but that doesn't make much difference)...

Rewriting is probably more important than the language you rewrite in.

The key point for me is C++ stdlib doesn't include an HTTP stack, while Go's does.

Fair enough, but it was a bit of a foregone conclusion that he wouldn't want to develop/reuse a C++ HTTP stack as he went into the project with the intention of using Go...

Here is a work in progress by another googler: http://cpp-netlib.org/ (Dean Michael Berris)

Actually, an awful lot of the "we rewrote X in language Y" stories on the internet have this as the true story, even if they don't admit it. (The LinkedIn mobile rewrite from Ruby to Node was like this. The official line was all "here's how to kick it in Node", the truth was the original implementation was single threaded across all users.)

That said, I'll happily read this story over and over again, because it tends to provide insight in what works and what doesn't.

Its also probably a lot easier to maintain now due to ...

- Gofmt; code formatting

- Smaller number of language keywords compared to C++

- Garbage collection

- Built in concurrency

- Simpler error handling (no C++ style exceptions)

The original codebase suffered from reinventing the wheel - badly. By composing together well tested high level abstractions, most of the tricky, broken parts could be removed from the responsibility of the application codebase, leaving only appication specific concerns. It could have been done without Go, but Go provides a good set of tools for the task. In C++ land, on the other hand, there isn't such a clear Right Way to do such things (though there are plenty of options).

Reply on news.ycombinator.com