As far as I know CPython is quite welcoming. However, per the blog post, this version of Pyston is closed source. So CPython won't be interested, and many others won't be interested either.
Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769
It's a shame how the core maintainers see CPython as a "reference implementation", rather than an opportunity to make a world-class programming language implementation. That the CPython maintainers have, time and time again, decided for a "simple implementation" has pushed away many professional VM engineers and researchers who would be more than willing to help maintain a JIT.
I also will say that a lot of the complexity of making a Python JIT is all the weird edge cases and special interpreter functionality. To a VM engineer, CPython is a very bizarre codebase; all the complexity is tucked away in corners other than its C codebase.
If anyone is curious, it is available on the Docker Hub but it seems it's a version from 4 years ago based on https://hub.docker.com/r/pyston/pyston/tags .
Whoops, I forgot we had that up, I took it down until we can post an up-to-date image
Maybe. One of my projects at work is supporting a legacy ColdFusion website that is nearly 20 years old (well, it was started 20 years ago, but has seen updates since). We'd love to move it to something faster, but it is huge and it would literally take years to rewrite it. Other things take priority so it will probably never be rewritten. I imagine there are Python projects in a similar boat.
Rewriting parts of it will not take years. Most of it can probably be thrown away, replaced by standard components. (only talking from personal experience, sure we had legacy systems running for years).
Unfortunately that wouldn't work with this site. Between the five of us in my group we have nearly 100 years of developer experience. We've talked a lot about if there is anyway we could divest of it a little at a time or replace parts of it, but we really can't.
20% isn't nothing... but is it really worth switching to a non-standard, closed-source version of the interpreter?
Depends on your scale. If each of your web servers has a hand picked name, definitely not. But if you stopped naming servers a long time ago, and if the pricing structure is favorable, it could mean a huge cost saving without an expensive rewrite.
As far as I know CPython is quite welcoming. However, per the blog post, this version of Pyston is closed source. So CPython won't be interested, and many others won't be interested either.
Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769
it's _still_ essentially the same switch(opcode) based interpreter it was 20 years ago. no threading, no super instructions, no jitting, nothing.
I feel like anybody really searching for speed is using something other than Python. I don't use Python for speed, but for ease-of-use. It took me some clicks to see it's supposed to be a drop-in replacement, so that's good.
I use python because of Numpy, Scikit and Tensorflow. I don't know of any other languages with libraries as productive as these, so speeding these apps up is a big win for a lot of people. Also 20% is huge, I look forward to trying it!
I'm in 5he same bucket here. My other ecosystem products are built on top of python, so we make use of pandas, numpy, dask, and our vendors own modules (which have taken them 10+ years to put together with a reasonably full team).
Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769
This is why I see little hope for Python, which is to say that while I'm sure it will continue to have a large following for many years a la C, C++, etc, I don't have hope for it being an exciting language or one that is particularly productive. Python already has performance and packaging problems which don't seem to be easily divorced from CPython, since virtually the whole reference implementation is depended upon…
100% agree. To a very real extent, Go probably only exists at all because Google poured an infinite amount of effort into Unladen Swallow--a project designed to remove the GIL from Python 2 to make it more usable for concurrent programs and add an LLVM-based JIT compiler to improve performance--and Python's response was to not only not merge it, but to break the entire Python ecosystem for a decade by forking the language... while somehow leaving "concurrency" and "performance" off the list of goals while making their backwards incompatible change (which of course also destroyed all the work on Unladen Swallow); hell: early versions of Python 3 were benchmarking universally slower than Python 2 :/. Google seems to have "gotten the hint", and around the same time (2009) hired Rob Pike to do Go, and has since "moved on" from Python and taken a massive part of the ecosystem of users Python used to have with it (the rest having bailed for node.js; remember when Python was the future of web development, competing with Ruby thanks to Django? those were the days): people still use Python, but it is now an entirely different crop of data scientists and AI people... all of whom are starting to run into the performance issues in even their glue layer, and so if the Swift tensorflow efforts ever work out, Python is done.
Ugh. At some point we need to stop using side-forks/-projects like this because then they become competing standards that pull resources away from the main projects and evolve into their own incompatible beasts. I hope they instead contribute to the main branch, instead of wandering off into NIH land.
Interesting to see that it significantly outperform pypy on some metrics, but wouldn't have it been better to allocate the human resources towards pypy instead of a duplicated effort?