"The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
Rob Pike has his ambitions. Great. Meanwhile, almost no one at Google uses Go. They use C++ and Java almost exclusively. Not Python either, outside of Youtube. (There's a reason GvR left.... all of the stuff he was proud of writing in Python got re-written, e.g. Mondrian.)
Pike is right that a significant fraction of Googlers are young and fresh out of school, and aren't 'researchers' (like maybe 33%?). They're also crazy smart, and can learn whatever language you need them to. Note that Google makes new grads learn a new storage model (BigTable etc), learn a bunch of custom infrastructure (everything except compilers and VCS is custom-built), learn all sorts of crazy shit. What Google does with these facts about their developers is that it uses C++ for huge-scale things (underlying infrastructure like BigTable, or massive-scale products like Search) and Java for the less-incredibly-demanding. Not Go. Unless you're Rob Pike and someone asked you if you could take care of something that needed a rewrite anyway.
It only makes sense to talk about Go as a Google language if you are under the mistaken impression that there are about 40 engineers at Google.
Look at https://golang.org/doc/faq#Is_Google_using_go_internally That's basically an admission of defeat. "We eat our own dogfood, and also a few tiny projects use it (one of which is tiny but super important)." Note that "scaling MySQL" is not exactly a long-term priority in a company that built three or four alternatives to MySQL, all superior.
It's possible that, if Google were starting from scratch, that ideas like "write the fast stuff in Rust and the less-urgent stuff in Go, which is still fairly fast" would be good choices. Sounds like a good idea to me. But the value proposition of Go over Java is, I suspect, not big enough to bother turning the enormous ship.
I'd love to hear any current Googlers chime in about a Google product written in Go that actually matters and took more than a hundred engineer-hours to write.
The linked section of the FAQ was written a few years ago. I'm not a Googler, but I can tell you some things visible from the outside.
>Note that "scaling MySQL" is not exactly a long-term priority in a company that built three or four alternatives to MySQL, all superior.
It might be more valuable than you think since GCE sells a hosted MySQL service. I'm speculating here; they could be using something else that's MySQL-compatible, but I doubt it.
>I'd love to hear any current Googlers chime in about a Google product written in Go that actually matters and took more than a hundred engineer-hours to write.
Kubernetes is a non-trivial Go project largely done by Google that's important to the future of GCE.
How is Kubernetes important to the future of GCE? I don't believe thats the scheduler they are using for compute. I know you can run Kube on top of GCE but that's obviously not the same thing. I was also told by someone at Google Cloud that when you launch a compute instance on GCE its actually running inside a VM as well. So this container inside a VM leads to me to think this is true. The VM might be for security, I'm not sure.
Note, however, that kubernetes is not used within Google (rather, they use a C++ alternative).
Part of why kubernetes uses Go is that it's in a docker-centric container ecosystem. Docker picked Go for its own reasons, not because of Google, so in a way, Kubernetes is picking Go because of the outside community, not because of Google or the language itself.
GCE operates GKE which is a hosted Kubernetes as a service. I'm not saying that Google is using Kubernetes instead of Borg, but that doesn't mean they don't use Kubernetes at all.
So, people are using Kubernetes in the Docker community. Google offers a GCE service for that. This seems incidental to Go with community and demand really driving its use. That they avoid it internally where possible is still a strong point given the large ecosystem developing around Go. Assuming it's true that they avoid it for C++ and Java of course.
Oh I was just commenting similar to this above. Is the C++ alternative Borg? I believe this spins up a VM like KVM and the runs the container inside the VM.
Not that it's necessarily better if the projects you are making take over a hundred hours to write, because it does suggest an attraction to monolithic designs.
That vontradicts the reported justifications for their selection and interviewing processes. He's telling us they can handle all that but not learn Rust like many average programmers are doing successfully? Does. Not. Compute.
EDIT: quote at 20:40. Not a response to the question.
Do you have a timestamp for this quote? It would be interesting to hear the context--what was said before and after. Was this a response to a question?
-- Rob Pike (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro...)