Pypy and Pyston are still quite a bit faster than CPython, but this is a huge improvement in one release.
Fond memories: I did use pypy or a predecessor in like 2004 I think when I took part in a student computer science competition and my algorithm searching for subgraphs wasn't performing well enough to terminate in time.
Pypy, as a practical software deployment runtime has been and will remain esoteric (I do absolutely think that they had a positive impact on the wider python community, both in terms of dissemination of ideas and also practical engineering artifacts). But what's their market share relative to CPython? A thousandth of a percent or less? Has anyone actually built a significant business on top of Pypy?
There is, IMO no realistic path at that point that Pypy could become a viable CPython alternative. They are effectively competing with a hostile platform they need to maintain an extremely high amount of compatibility with, and that can and does move in directions that invalidate some fundamental engineering choices they make. Practical end results include that they're stuck w/ a lot of crippling design decisions (GIL, FFI API etc.) and a core part that is still in 2.7 land (RPython) and have historically mostly only been compatible to very outdated versions of python. This has improved a lot, but the next time CPython throws another curve ball the same thing is bound to happen again.
The only chance they really had was to be compellingly enough faster or otherwise superior that community pressure would have forced the CPython team into adopting a much more collaborative stance. That seems very unlikely to happen, now after all this time, given that now CPython is catching up and they have the albatross of the C extension ecosystem around their neck. Almost anyone who cares about python performance outside of algorithmic programming competitions will be using C extensions where Pypy offers no compelling advantage, some disadvantages, and by the momentum of the existing eco-system is unable to develop a superior alternative.
Isn’t mypyc effectively an alternative (AOT-compiled) Python implementation? Guido doesn’t seem too hostile too it.
If PyPy had a similar mode where you could load it as a library it would have a much easier time gaining traction.
> Simple "JIT" compiler for small regions. Compile small regions of specialized code, using a relatively simple, fast compiler.
https://github.com/markshannon/faster-cpython/blob/master/pl...
[1] Random google result as source: https://www.cyclonis.com/microsoft-edge-tests-disabling-java...
My opinion is that it's mostly a curse, since you are hampering the language's evolution and growth for a mere temporary benefit.
Not to mention the horror of distributing compiled libraries, which is one of the biggest reasons why packaging in Python is still such a nightmare.
Making CPython faster by getting rid of the GIL will do wonders for this language and it's community. It will make it much more portable, too. Think of Java-level portability, but in a much nicer package.
A couple of them have valuations in the trillions of USD, actually.
(Mozilla does support a ton of OSS, too, so read that as everyone else needing to step up rather than an attack on them)
All I’m saying is that asking why JS performs faster than Python in some cases is less about the languages and more what you could do with hundreds of engineers working for years. If the stars had aligned differently and that effort had gone into Python (or Ruby, etc.) I’d expect a similar delta.
I’ve heard this “no C API” thing echoed by a couple people and it’s baffling. Do folks really think three major JS engines all written in C++ wouldn’t have an interface to interact with C?
Python's C API exposes ref counting and the GIL. It's also very large
JS doesn't have that problem -- more code is written in pure JS, there are no C/C++ bindings in the browser.
There are C/C++ bindings in node.js for v8, but as far as I know they are discouraged and not used very much. The bindings are more "first party" in node.js than third party.
They have issues, but not the same ones as CPython, because the API is very different
JS VMs must be re-entrant because they're embedded in browsers. That was never the case for CPython
Fwiw, this a fully stable and well documented API. It’s not even v8 exclusive, Bun cloned it for WebKit.
JavaScript doesn't interact with random C libraries that the user might have, like Python does.
JavaScript does interact with random C libraries :)
Being dynamic make it harder to be fast, but JS/v8 is as dynamic as python, and much faster.
Those features are not in common use. Python’s hard-to-optimize dynamic features are more commonly used.
Javascript never had this problem, as all code was always written in Javascript itself by necessity, so it was far easier to optimize as you did not have to worry about backwards compatibility of the internals.
For C/C++ extensions, I think there may be hope to support a slow/emulating C API and a faster, less internals-leaking new API that extensions could adopt. It would take years for the migration, but if speed gains was say 5x, I think it could be realistic.
pypy managed to emulate the C API fairly well, after all. E.g. you can build numpy and pandas on top of pypy and it actually kinda works.