OP here. It is absolutely true that we did not rewrite the entire original system in Go; I tried to be very explicit about that in the blog post. But, I feel confident that it could be done, in much less code, with greater clarity and modularization. The Go language by itself does not force good software design. A rewrite in any language would have been better than the original system, but our decision to use Go turned out to be fortuitous in that we managed to do so in record time and with much greater programmer productivity.

I'm glad to hear it.

Was there anything about the language that you found particularly forced clarity and modularity? I'm giving a talk comparing Go and Ruby next month and I'm curious as to what people with experience with larger Go programs find to be most helpful.

The Go module system for sure. Also I really like Go's interface model (as opposed to Java or C++ classes) as it is more flexible and in some ways more precise. Note that I don't know Ruby so I can't compare Go to that...

Thanks for the article, it was a very interesting read! Since this always comes up in Go discussions: did you miss generics in this project or was the lack of generics a non-issue?

I haven't found that I needed generics so far, though I can see places where they would be useful.

Hmmn. I think there's a fundamental advantage in any rewrite that's allowed to drop functionality - even a C++ to C++ rewrite.

It's not just the language. It's the fact that (a) you already have an instantiation of the idea to look at as a reference and (b) you're happily cutting bits off the original. The latter suggests that you're not only not supporting all of the original use cases, you're probably in a nice state of organization where you're free from the temptation to "astronaut" up a more general system than you really need.

It's always nice to have this power, but it shouldn't be confused with the wonderfulness of the language.

ironically, that's not the common experience; the term 'second system syndrome' was coined for a reason.

"allowed to drop functionality", as used by you, is a strawman -- the team _added_ functionality to the part they were rewriting without incurring the wrath of the second system. sure, the line counts are off, but your argument does not stand in the general.

If I remember Brooks correctly, second system syndrome does not refer to all successor systems, and frequently complex/over-built systems spawn elegant ones in turn (oversimplifying a bit, but MULTICS -> UNIX springs to mind). I seem to recall Brooks regarding this as cyclical, with leaner third systems spawning bloated fourth systems, and so on.

i was referring to recent examples such as python 3.0, perl 6, or even, say, apache 2.0. eventually they were usable, but the blood sweat and tears involved did not make for cute blog posts such as the one we're commenting on.

I think a component in a service oriented architecture would lend itself more cleanly to reimplementation, with less chance for "Second System Syndrome", because you still have an api contract you are responsible for.

I think a "released" software, like those you mentioned, would be somewhat more likely to become a stereotypical "second system".

>ironically, that's not the common experience; the term 'second system syndrome' was coined for a reason.

And the reason was overly ambitious rewrites of huge and complex codebases.

For simpler stuff and especially when cutting down on feature bloat, rewriting is fine.

There's a phrase about rewrites, by the same guy that coined the "second system syndrome": "plan to throw one away".

> It's interesting to see that more and more internal projects at Google are getting redone in Go.

I think one of the key drivers of this which hasn't come up yet in the comments is this one:

"The #1 benefit we get from Go is the lightweight concurrency provided by goroutines. Instead of a messy chain of dozens of asynchronous callbacks spread over tens of source files, the core logic of the system fits in a couple hundred lines of code, all in the same file."

I think it would be quite rare to see a project of any significance at Google which didn't have an async aspect to it. My guess is that this is particularly the case when it was decided to be written in C++ over Java or Python: speed for this project matters, and the way to get the fastest execution is a distributed C++ program.

When you combine that with Rob Pike's assertion that most of the programmers moving to Go are from Python rather than C++, and you can see why rewrites are starting to gain momentum. I think there are a handful of people who truly do love C/C++, but I think most programmers (Google or no) see it as a necessary evil to meet the desired speed requirements. Now Go is stable and proven to work at Google, I can see lots of teams getting internal pressure to start trading out components from C++ to Go. I can see managers greenlighting it (perhaps as a 20% project) if only for the readability argument.

This is why a "go" rewrite story is not that appealing to me. You can rewrite a subset of a system and gain many improvements simply by benefits of hindsight and clearer requirements regardless of languages.

Obviously, but the author is smart enough to acknowledge this and take it into consideration. So.. what's your point?

Original production code is messy, especially the ones that have been maintained over the years through multiple requirement changes. A rewrite will make those messiness go away, for now, regardless on languages used.