If all Python needed was a JIT, this would have been addressed over a decade ago. The problem isn't a lack of a compiler, it's language semantics that make the job of a JIT nearly impossible.
The usual urban myth, ignoring JIT work in language semantics like Smalltak, Common Lisp, SELF, where anything goes and the whole process space can change in a method call.
JIT doesn't happen in Python because the community rather rewrites code in C, than support projects like PyPy.
NVidia and Microsoft had to come into play to change this.
None of the languages you mention there get even close to C levels of performance when you hit "anything goes" dynamic language features. Those JITs are only competitive (i.e. within an order of magnitude perf) when you are accelerating very barebones code on native types and non-generic functions, or you strip out dynamism.
In julia, there is no separation between generic functions and fast functions, and no separation between user defined types and inline allocated structs.
This is not the case with Python, Smalltalk, Common Lisp, etc.
To actually take hold and stop people from relying on C libraries for everything in Python, the Python JIT is going to have to be as fast as C, and it's also going to need to have a CPython compatible ABI because people are not going to abandon all these pre-existing libraries overnight.
Python's semantics make both of those prospects incredibly dubious.
So I am lost, are talking about Python JIT compilers or C performance?
Smalltalk, Lisp and SELF were used to write complete graphical workstations, where a debugger code change or dynamic code load across the network could impact JIT decisions across the whole OS stack.
Python JIT compilers don't exist in a vacuum. If you want one to take over, it needs to be worth using. So comparing the performance of that JIT compiler to C performance is very relevant, since the goal has to be to replace code which was written in C with Python code.
At the same time though, because Python has such a tremendously big ecosystem, all written in C, and targeting specifically the CPython interpreter ABI, even if you make a JIT compiler that is as fast as C, it'd also need to support the CPython interpreter ABI, otherwise it'd never catch on because the JIT compiled implementation of the language would have to start fresh with almost no ecosystem support.
The situation is even worse if we take the realistic view that such a JIT compiler will make some serious performance compromises relative to the existing C code everywhere in the ecosystem, and the fact that the CPython interpreter ABI is so entangled with the internal implementation details that it's impossible to support in a way that's even approaching being performant.
Which goes back to the point of the community not caring about JITs, which is embodied in the way Python libraries that are thin wrappers around C code, get called as "Python" libraries.
They are as much Python as they could be Tcl.
Ironically it sufficed to Microsoft and CUDA step in, followed by Facebook as well, Guido gets out of his Python retirement, and JIT, GIL-removal are suddenly issues that matter.
That person seems to just think that so long as the JIT is kinda fast, it's good enough. But that's really not the world we live in most of the time, especially if using that JIT broke binary compatibility with existing fast libraries.
There's a gigantic graveyard littered with dozens of abanoned Python JITs, Psyco is hardly unique. The community has not at all gone down the PyPy route, nobody uses PyPy either, even if it's technically not abandoned.
There's little reason to think these new JITs will fare any better.
