python simply not scaleable enough for google?

[Terry Reedy]

Willem Broekema wrote:

> It might have gotten a bit better, but the central message still
> stands: Python has made design choices that make efficient compilation
> hard.
> 
>> OK, let me try this again. My assertion is that with some combination of JITting,
>> reorganization of the Python runtime, and optional static declarations, Python
>> can be made acceptably fast,
> 
> That does not contradict that, had other language design choices been
> made, it could be much easier to get better performance. Python may in
> general be about as dynamic as Common Lisp from a _user_ perspective,
> but from an implementator's point of view Python is harder to make it
> run efficiently.

I think you are right about the design choices. The reason for those 
design choices is that Guido intended from the beginning that Python 
implementations be part of open computational systems, and not islands 
to themselves like Smalltalk and some Lisps. While the public CPython 
C-API is *not* part of the Python language, Python was and has been 
designed with the knowledge that there *would be* such an interface, and 
that speed-critical code would be written in C or Fortran, or that 
Python programs would interface with and use such code already written.

So: Python the language was designed for human readability, with the 
knowledge that CPython the implementation (originally and still today 
just called python.exe) would exist in a world where intensive 
computation could be pushed onto C or Fortan when necessary.

So: to talk about the 'speed of Python', one should talk about the speed 
of human reading and writing. On this score, Python, I believe, beats 
most other algorithm languages, as intended. It certainly does for me. 
To talk about the speed of CPython, one must, to be fair, talk about the 
speed of CPython + extensions compiled to native code.

In the scale of human readability, I believe Google go is a step 
backwards from Python.

Terry Jan Reedy