Google and Python

[Bryan Olson]

Alex Martelli wrote:
> Bryan Olson <fakeaddress at nowhere.org> wrote:
>    ...
>>> YouTube (one of Google's most valuable properties) is essentially
>>> all-Python (except for open-source infrastructure components such as
>>> lighttpd).  Also, at Google I'm specifically "Uber Tech Lead, Production
>>> Systems": while I can't discuss details, my main responsibilities relate
>>> to various software projects that are part of our "deep infrastructure",
>>> and our general philosophy there is "Python where we can, C++ where we
>>> must". 
>> Good motto. So is most of Google's code base now in
>> Python? About what is the ratio of Python code to C++
>> code? Of course lines of code is kine of a bogus measure.
>> Of all those cycles Google executes, about what portion
>> are executed by a Python interpreter?
> 
> I don't have those numbers at hand, and if I did they would be
> confidential: you know that Google doesn't release many numbers at all
> about its operations, most particularly not about our production
> infrastructure (not even, say, how many server we have, in how many data
> centers, with what bandwidth, and so on).
> 
> Still, I wouldn't say that "most" of our codebase is in Python: 

Can you see how that motto, "Python where we can, C++ where
we must," might lead people to a false impression of how much
Google uses Python versus C++, especially on "production
systems"? I tried to Google-up that motto; your post seems
to be Google's first disclosure of it.

[...]
> To me, on the contrary, it seems
> self-evident that if a company X enjoys great success employing
> technique Y, this *DOES* make something of a case for another company Z
> to seriously consider and probably try out Y, when attempting tasks
> analogous to those X has had success with, to see if some of the success
> could not be replicable in Z's own similar tasks. 

Similar tasks to what made Google a great success? I'm not
seeing many of those.

People seem to think they should duplicate the way Google
does things, but without deep understanding of how and why
they work for Google. An impossible task, because it's
about the most un-Googley thing anyone could do.

> This is the heart of
> "benchmarking" and "industry best practices" -- and why many companies
> in the role of X aren't all that forthcoming about publicizing all the
> details of their Y's, just in case Z's endeavours should put Z in
> competition with X (this always needs to be balanced with the many
> _advantages_ connected to publicizing some of those Y's, of course).

In the case of Google, there's way, way too much hidden for
people to reason based on what Google does. In this thread,
did you notice how far wrong people went about how Google's
stuff works?


> Such empirical support, while of course far from infallible (one will
> always have to take into consideration many details, and the devil is in
> the details), tends to perform vastly better in supporting decision
> making than purely abstract considerations bereft of any such empirical
> underpinnings.

Wikipedia is in PHP, Slashdot in Perl, Basecamp in Ruby. They
all rock, but more importantly, we can look under the hood. If
Wikipedia makes a weaker case for PHP than Google for Python,
it's largely because the whole story is never as neat as a
trickle of selective disclosures.


-- 
--Bryan