I really think PyPy is the future of Python. A faster python with better support for paralellism by leveraging STM. This makes Python suitable to a lot of use-cases where it's currently too slow. What is lacking at this moment is compatibility with a lot of the libraries in the ecosystem (see https://bitbucket.org/pypy/compatibility/wiki/Home), due to limited C-API compatibility (which is non-trivial to say at least due to different memory management and locking semantics). This is serious because a big part of what makes Python so cool is the wide library support.
Yet it only really address part of the problem. AFAIK, right now pypy is a memory ogre that would not fit on a mobile. If someone with Pypy knowledge would enlighten us about if it will ever be possible to run it on a 1 GB mobile phone or a tablet ?
Right now memory usage is pretty bad. But mind that tablets and phones will have more and more memory in the future, while at the same time, very smart people are working at improving PyPy. I'm pretty optimistic in that regard.
After all: If it's possible to get JS JITs to fly on mobile devices, which it is, why not Python? I really see no structural problems.
I tend to agree with you, it will happens. But Python is loosing mindshare right now, won't it be too late if we wait to get to the point where both Pypy consume less memory and device have enough memory ? I think that's the point of the article is what can be done now to not be late on the bandwagon and surf on latest trends. We are somewhat talking about platform marketing here, I think.
The latest-trend-kids will always be doing their thing. Python will never be as hot to them as when it was new. It isn't really a problem. It is possible that NodeJS, Golang never reach the popularity that Python gained in the first place, because the cool kids will jump the bandwagon again and again for something hotter and newer. It's not where the real work is happening, they're just the loudest.
I see more people around me learning Python every day, because it is a useful language to get stuff done, has excellent bindings for almost every other library, and is pretty stable (ie, the language has been about the same for a long time).
Could you clarify what you mean by "third party libraries"? Do you mean libraries written in Python like those [which are pure Python] on http://pypi.python.org/pypi ?
These are not all written in Python. A lot of them are actually C or C++, some are Haskell or Fortran (that's no error, Fortran). Even the ones written in pure Python often ultimately depend on something that's just a wrapper over something in another language. In fact, could be an interesting side project to determine how much of PyPI doesn't work with PyPy...
BTW I just discovered that there is a project called cppyy, as part of PyPy: http://doc.pypy.org/en/latest/cppyy.html
It looks pretty cool. When it's possible to directly use C/C++ libraries, the raison d'etre for a lot of the third-party bindings that use the C-API disappears.
Yes, I knew that. There was an implicit (now explicit) "written in Python" in my comment above.
(The purpose of my original comment was because PyPy does work with third party libraries, especially if they are pure Python, and so I was asking if these were the sort of libraries that were being referred to.)
It's not faster. It's only faster for specific use-case, running the same stuff for long time in a loop. This use-case is a good fit for running webapps, but not small scripts, hooks, mobile or desktop apps that trigger some (relatively) small amount of (different) work randomly (on user's activity).
To be fair, almost all longer running applications fall into the "same stuff for long time in a loop" category. Whether it's a GUI event loop, rendering, scientific computation, or a network server.
Sure, very small scripts and hooks only do one thing one time, but usually those aren't the things that benefit from being heavily optimized in the first place, and could just as well be left interpreted (even better -- as interpreted code is more compact and thus better fits in the cache). The same holds for every other JIT-based language.
Well, I'm actually not sure they do. I'd like very much to get some real-world example and experience to see. But until then, I don't think that clicking the same button >1000 times to make JIT work will be faster in real life.
Overall, PyPy lefts expression as project that "gets fantastic things done" and I'm looking forward using it everywhere I can.
