Google Programming Preferences, the Python Ultimatum
December 6, 2009
A thread on Google Groups’ Unladen-Swallow tackled the question of what programming languages are encouraged or discouraged at Google. At the conference in London on December 2, 2009, I heard that Microsoft wanted developers to use Visual Studio.net, yet Windows 7 and other Windows products were anchored in Assembly language and C, often undocumented Assembly language and C. Whether true or not, the resulting conversation triggered on person to mention the Unladen Swallow thread.
I hunted down the group and noticed several interesting points.
First, one group participant asserted that Python is not as zippy as Java or C++.
Second, Unladen Swallow included this passage:
Unladen Swallow aims to shift the balancing points in that tradeoff to make it possible to use Python in more places where it would currently be unsuitable, but it’s not going to be a panacea. Python will still be slower than C and Java, use more memory and have inferior threading until someone decides to invest resources into Python comparable to what, say, Sun has invested in their JVM. I hope a focus on Python performance by the developers will start a snowballing effect: more companies are interested, more resources can be devoted, more grad students will work on Python (and actually commit their work), etc.
Third, on the issue of JavaScript, there were some comments. Among them was this one:
I don’t think it’s possible to make an implementation like CPython as fast as an engine like V8 or SquirrelFish Extreme that was designed to be fast above all else.
Fourth, on the subject of Jython:
Another one of unladen-swallow’s major goals is to maintain source-level compatibility with C extension modules, which Google uses a lot of. Using Jython would require moving that infrastructure from SWIG to JNI, which would be a huge pain in the butt.
To which, this comment was added:
Jython has a similarly-small number of paid full-time developers (and Frank W just left Sun, as you may have seen). To date, IronPython and Jython have had to dedicate a significant portion of their engineering resources to achieving compatibility with CPython, with relatively little time left over for performance optimization. It remains to be seen how these factors will be balanced as Jython, IronPython, PyPy, etc move to support Python 3.
Finally the comment I found most interesting:
One area where I believe Python (and other dynamic languages) do particularly well is projects with lots of developers working on lots of little subsystems, all contributing to the same codebase or the same released binary. In a language like C or C++, the more developers you add, the more fragile your binary becomes: it only takes one segfault to kill a running binary (and hence lose those pending requests), and the probability of introducing that segfault goes up with the number of developers/subsystems/integration points/etc. Dynamic languages, on the other hand, are much easier to sandbox in this regard. If you want to isolate failures in one particular component in your Python system, you can just throw a try/except around it and you’re basically good to go. That kind of agility and flexibility is an important advantage, and it’s one of the “other merits” I was alluding to above. Python may not be a good fit for millisecond-critical systems, but it
does have advantages; we wouldn’t use it if it didn’t.
What is clear to the addled goose is that this discussion of performance at a fine-grain level is part of Google’s now public effort to make the Web speedier. The addled goose wants to point out that with each “make the Web better”, Google takes a baby step closer to becoming the Web.
This is a big idea but it grows from fine grained engineering emphasis on performance details. Now about that Office 10 beta load time?
For criticism of some Google practices, navigate to Google Releases its JavaScript Closure Tools. For a critical discussion of the Google Go language, check The Most Intriguing Concept In Google’s Go Language. More information about Google programming appears in my Google trilogy.
Stephen Arnold, November 2009
Again I must report to the General Services Administration that I was not paid to write about a performance discussion of Python variants at the Googzilla facilities. Speedy “services” remain the exclusive domain of the General Survives Administration, so Google has a long way to go to achieve GSA velocity.
Comments
One Response to “Google Programming Preferences, the Python Ultimatum”
-
- Subscribe to Beyond Search
Feature archive
News archive
-
We’ve built a lot of Flax in Python, around the Xapian core (which is written in C/C++ for performance). It’s an incredibly flexible and useful language, and it means we can create solutions for customers very, very quickly.