Hacker News Reader

Comment by MatthewPhillips | Hacker News Reader

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.

View on HN

Remember Vitess? It sits in front of all of YouTube's databases. Every time you load a page on YouTube, the database queries go through Vitess.

http://code.google.com/p/vitess/

It's a sweet program, and if it stops working, then YouTube gets smashed by a fail whale. Would that be the kind of thing you're looking for?

If dl.google.com fails, Chrome installs halt. By what definition is that not shit hitting the fan?

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.

Yeah. People aren't understanding what this is running. It's serving up files to a CDN. That's not that exciting.

I work on Google's CDN. I have an intimate understanding of what's running here.

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

Just because Googlers can't publicly speak about using Go for serious shit doesn't mean they aren't.

> Google uses Go for many internal projects, but for confidentiality reasons it's rare that we can point to a specific example

Internal projects aren't serious shit.

How can you possibly know that categorically? Internal in this case really only means "doesn't talk about it publicly".

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.

I am starting to think that this is not just about a programming language to you.

1) They don't owe you anything.

2) "Internal projects aren't serious shit." is absurdly overreaching. That is all I was saying in response to you.

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.

Do you honestly think they are lying? They aren't selling anything here...

The Java people had a very storied history of overstating

1. What was possible with Java in terms of performance

2. What use-cases were practical with Java and the JVM by conflating practical with "vaguely plausible or possible"

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

Reply on news.ycombinator.com