"We needed a high level of compatibility and reasonable performance gains on complex, real-world workloads. I think this is a case that PyPy has not been able

"We needed a high level of compatibility and reasonable performance gains on complex, real-world workloads. I think this is a case that PyPy has not been able to crack, and in my opinion is why they are not enjoying higher levels of success." It's a little tiring, as somebody who regularly puts production workloads onto PyPy, to hear this bullshit. The truth is that PyPy has been regularly spanking Pyston on benchmarks[1] and has been adding Python 3 support while Pyston has struggled to handle its Python 2 commitments. It's great that you wanted to build a JIT. JITs are fun and cool. But if you just wanted shit to work, you could have used PyPy years ago and not jumped through all these hoops. Yet again, the fact is that if you invested any code into C extension modules, you picked the wrong path. Good night, Pyston; you were a cool experiment and I hope that your contributors try sending patches to PyPy next time. (Pyjion, you're next.) [1] https://pybenchmarks.org/u64q/benchmark.php?test=all&lang=pyston&lang2=pypy&data=u64q https://pybenchmarks.org/u64q/benchmark.php?test=all&lang=py...