Google's a huge company and its products have a wide variety of requirements. For context, dl.google.com is basically a download server: its goal is to get static files from Google's servers to your client as quickly as possible, with some minimal business logic. Something like this is basically ideal for Go, because it is relatively stateless and focuses on shuffling bytes from one IO interface to another. Another ideal use-case was the project that Matt Welch blogged about moving to Go.
When most laypeople think about "Google", they probably mean the search engine. I cannot imagine the serving system of Google - the part that actually retrieves the results and ranks them - ever being written in anything but C++. The scale of data that it operates on is just too large, the complexity of the code too high, and the CPU budget per request too small.
Now, there are other binaries in the search serving stack that I think should ideally be written in Go. I said as much when I was at Google, though I doubt it'd ever happen simply because of inertia. But that's probably not what people are thinking of when they say "Google-scale".
By "the part that actually retrieves the results and ranks them" you mean the nodes of a cluster, that run the RPCs?
I guess the "hotspot" would be the code that has to merge the top results from the different nodes and actually deliver top rated 10 items to the user?
That some google services were rewritten in golang doesn't really say much, in a video Rob Pike himself said that lots of services in google can't and shouldn't be rewritten in Go because of the GC, the video: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan... - At 31:20 Andrei starts talking about the problem of the GC with the scale of Facebook, you can start watching there.
