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...
