My notes on the Q&A after the keynotes are a bit rougher, so I’ll summarize.
Guido asked when they would open source their (really cool sounding) built system. Greg said that the build system, like a lot of the stuff they use doesn’t make a whole lot of sense if you aren’t running on top of their google platform. Later in the Q&A Greg noted that when they perpare bits of code for release as open source the software usually gets better in the process. They also have some people working on untangling some bits from the google platform for release, so keep an eye on code.google.com
Someone brought up Boost.Python, which is said to handle templated C++ code better. Greg was unaware of it, but they seem quite happy with SWIG for exposing C++ code to Python.
Someone else wanted to know if they used Python for network monitoring and SNMP. Greg said that the ops guys keep a close watch on the traffic and that he usually has to inform them in advance when he needs to transfer “big” files.
Alex Martelli, who starts working at Google in 3 days, wanted to know how SWIG dealt with templated code. It’s not great, but there are ways to get around simple templating.
Another audience member wanted to know what Greg thought was missing from Python and what could be done about it, and how google dealt with programmers that feel more comefortable in c++ or Java. The first question was answered by the fact that they hired Alex. It was also interesting to learn that they run Python 2.2 on their servers. They would like to upgrade to 2.3, but that’ s a non-trivial task. Each engineering team decides what language they work in, and that’s not a huge problem because they make use of SWIG to cover the C++/Python bridge and they make extensive use of RPC so that it doesn’t matter what language each little bit is written in.
When asked about how many engineers work at Google, Greg pointed to the public numbers, but wasn’t able to break it down further. A couple hundred perhaps.
Google uses a derivative of Bugzilla for their bug tracking, but they would like something better, and are investigating other options.
Everyone seems to equate Python with slow, but that hasn’t really been a problem with Greg or Google. When eShop got bought by Microsoft a lot of Python code was rewritten in ASP/COM and the resulting code was slower than Python.
When asked about the total number of lines of code written in various languages, Greg reckoned that there were probably more lines of C++ than anything else, followed by Python and then Java (Blogger is written in Java).
David Asher asked Greg about a patch to Python 1.4 a few years back and how that might be useful in the future with multiprocessors becoming so popular. Back in 1996 Greg patched Python 1.4 to remove the global interpreter lock and keep track of things that needed to be locked in other ways. His patches worked great on a single processor machine, 2 processors was a bonus, but once you got to 3-4 processors it was slower. He hasn’t run in to trouble with the global interpreter lock at google.
Google doesn’t have debugging tools per se, but they do extensive logging (Greg likes “print”) and have good tools to analize those logs.
Greg’s work projects include code.google.com as well as some internal stuff. For fun he works on Subwiki (in Python of course) along with the ton of other projects that he’s worked on over the years.
They didn’t use an off the shelf web application framework for code.google.com, they built on top of the Google http server written in c++. GMail was written in C++ not Python.
When asked how they stage, Greg said that they can route a small amount of traffic (say 1%) to “Canary Servers”. If these servers don’t fall over, they can slowly pump more traffic to the new version but can easily and quickly set a previous version as the live version.