[sandGorgon]

Which is why I'm very excited about Graal Python (https://github.com/graalvm/graalpython/blob/master/README.md)

It has the potential to bring an underlying framework which is built on industrial quality VM+JIT and it's primary goal is being compatible with the Scipy ecosystem at least ...Which is reason enough for unlimited optimism.

[ris]

> industrial quality VM+JIT

I'll skip over this mostly, just wondering what exactly you mean about this and whether you consider LLVM not to be "industrial quality" seeing as the failed Unladen Swallow project based itself upon that and it didn't seem to get them anywhere.

> it's primary goal is being compatible with the Scipy ecosystem at least

Well... it's not like PyPy isn't "compatible" with the scipy ecosystem. It just has to use a lower-performing object access mode to use cpyext-based extensions, which I suspect is a compromise any JIT-based implementation will need to make to be able to make use of these more old-school extensions.

Ironically on the subject of "industrial quality" JITs, GraalVM is based upon the same meta-tracing interpreter ideas that were largely pioneered by PyPy.

[sandGorgon]

Llvm can't be used. I wish it could - http://doc.pypy.org/en/release-2.4.x/faq.html#could-we-use-l...

I'm not sure about your point. There is a new Python version built on Graal, that promises to largely maintain C compatibility (like graal Ruby) and still deliver performance.

I wish Pypy were getting funded by someone and have a lot of respect for what those guys achieved...But the fact remains that it is not bring used. Maybe graal Python can change that.

I used the words "industrial quality" instead of "pioneering" or "innovative". I think it's accepted that the millions of man hours spent on the JVM has made it one of the most incredible VM anywhere - is the defacto foundation on top of which you build big data (spark/hadoop), language theory (scala, closure, kotlin) and a billion mobile phones.