> Why rewrite in Go? It all started back in April of this year, when I was running "apt-get update" at home and noticed that downloads from dl.google.com were stalling for no apparent reason. I asked about this on our internal Google+ and was put in touch with the right people. It turned out that the existing C++ dl.google.com service was no longer actively maintained (short of being kept alive) and that it relied on some assumptions about Google's internal architecture which were no longer true.
This doesn't instill confidence in Go. That it is a success story with abandoned projects is not what we need to hear; we need to hear that Google+ runs on Go. Or at least something the size of Google Reader. When a startup is evaluating what language to build their stack on, dl.google.com is not what they're aiming for.
Apparently an unmaintained C++ app using deprecated libraries and making false assumptions about Google's internal architecture was able to handle it too, albeit with poor performance. So I disagree that this move says anything about Go's capabilities, positive or negative.
I'm inclined to agree that by itself, this doesn't say much about Go at all.
That said, I'm not sure how much a non-open-source program can really do in terms of marketing Go or any other language. This isn't so much politics as logistics: you need to be able to see the difference in code to get a sense of the advantages or disadvantages of one language over another, and if the program isn't open-source you can't do that. The author can say it's "more readable" (and does, in fact), but that's not something that can be quantified, and so there's really nothing but one guy's opinion to go on.
Yeah, but the top-layer app is where the author's statements would bear out: that's the code directly comparable to the old C++ code that it replaced. It's not really practical to give examples of that when you can't open-source the app; you could maybe do a few trivial snippets or put it all behind a big thick NDA, but neither method works very well.
At least it says that Go works for replacing legacy apps that are using deprecated libraries and making false assumptions. There are tons upon tons of such programs in the world.
It doesn't necessarily hold. You can write a system which handles huge volumes of traffic simply by scaling horizontally with N servers. For some languages N is just a lot larger. Unless your startup has unlimited hardware resources like Google you can't make that assumption.
Wait, so your opposition to Go was that it was cost effective and powerful enough to merit investing engineering time to replace a broken legacy system that couldn't justify the expense of C++ maintenance?
My "opposition" (not the right word) to Go is that the company which created it doesn't use it on anything that is serious enough to cause a "shit hits the fan" moment were it to fail. Other than it works badly on Windows, I don't have any reason to think Go is inadequate, but if Google hasn't bought in yet, why should I.
Not quite.. it seems the Go app is just a webapp run on the origin server(s) that their CDN pulls from. Chrome installs/upgrades would only fail once whatever caches expire.
Yes but the CDN itself is not Go, correct? That's kinda the point here, that nothing all that critical or core to the processes themselves are implemented in Go, even if the service as a whole functioning entity are important.
They want to know Go can be trusted to do the heavy-lifting most people would use C++ or Java for. So far, nothing that Google has publicized about how they use Go has indicated that their concerns are invalid.
How are you distinguishing between what's "critical or core to the processes themselves" and what's not? What makes taking bytes from a disk or memory cache and pushing them over a socket somehow more "critical" than getting the client to the right server in the first place? Neither one is useful without the other: it's a cohesive whole that now works much better since dl.google.com was rewritten in Go.
I'm genuinely interested in this particular objection. I've written several components of a multi-component system (itself just one major piece of what makes our CDN work), and it never once occurred to me to say that one component was more or less "critical" than another. In this system I've written 12kloc servers with intricately managed resources where cachlines matter, and I've written 1kloc servers that just repeatedly make internal RPCs and occasionally tweak the behavior of the system. I've seen the system's behavior when each of these components fail, and both sorts of failures cause major problems. Is one more critical than the other? I'm going to get paged and users are going to suffer whichever one fails.
You don't understand the objection precisely because you work at Google. :)
The reason that people are objecting is because serving up files is not exciting or innovative and doesn't show any particular 'win' for a language -- I could write the same thing in Haskell, for example. The details about how it's serving up the files from your Googley FS are irrelevant to the non-Google employee. :)
I.e. I can run nginx on any machine with a decent CPU and saturate a 10Gbps link serving static objects.
If you were to say that the gigantic global network of awesomeness that is Google CDN runs on Go, the average non-Google employee starts to care because that's something that you can't just do with some off the shelf OSS software. Then we can start taking Go seriously for mission critical use.
That's the though process, anyway. If you don't agree with it, that's perfectly fine. :)
Burden of proof is on Google to show that they are using it seriously which, to me, means an external user-facing application that has importance to Google the company's bottom line. If they aren't taking the same risks that a startup that decides to build with Go is going to be taking, it says a lot about Google the organization.
Internal projects are not something that I can judge the importance of, so pointing out that they use Go in internal projects is asking me to take their word that they are taking Go seriously, but all I'm saying is "show me". Show me on a project I've heard of. We know they have faith in C++, Java, and to a lesser extent, Python.
> Internal projects are not something that I can judge the importance of, so pointing out that they use Go in internal projects is asking me to take their word that they are taking Go seriously, but all I'm saying is "show me". Show me on a project I've heard of.
I assume you have heard of YouTube. From the first paragraph in the email:
> YouTube’s open source vitess project (http://code.google.com/p/vitess/) is one high-profile success story...
This doesn't instill confidence in Go. That it is a success story with abandoned projects is not what we need to hear; we need to hear that Google+ runs on Go. Or at least something the size of Google Reader. When a startup is evaluating what language to build their stack on, dl.google.com is not what they're aiming for.