Posted by f311a 22 hours ago
In my view, the right course of action is to specify an official strictly typed subset of the language with compilation and static analysis as the justification, then implement both JIT and AOT on top of that. Legacy code can be rewritten or thrown out in phases, C extensions can be ported.
Of course, any such proposal would invite monumental amounts of bikeshedding, which is why it wouldn't get far, much like the JIT proposal.
This is a great idea for popular dynamic languages with existing users and codebases, particularly the focus on "subset" to limit the scope and emphasizing that full backward compatibility is not a goal; and allowing for gradual, incremental adoption. That makes it a lot more practical to implement and adopt.
I think we'll see more of this. Recent examples include strictly typed TypeScript subset designed for ahead-of-time compilation.
Python in itself is poorly suited to ever become performant as it lacks the types required. I imagine that causes some issues for effective jit-ing too.
They had a chance to fix this when adding type annotations, but instead of making it "optional/gradual typing" they opted to make it "documentation or linting support", which is obviously the wrong choice, but there were cultural reasons
If it helps python specifically, given that the types themselves are pretty dynamic, who knows. A python integer doesn't map well to a native integer etc. Python really isn't designed for performance, and retrofitting it is hard.
To me, goals without plans behind them aren't really goals at all
As usual, though, I might just be biased by default towards defending the Python aristocracy; they seem to pretty much always be on the right side of history, even in the little ways!
Python is my favorite language, but I'm honestly tired of having to rewrite performance bottlenecks in Cython or Rust all the time. When the Faster CPython project started with Microsoft's backing, I was really excited. Mark Shannon had that plan promising huge speedups across a few cycles, and while that clearly turned out to be much harder than anticipated, the team still kept pushing forward to deliver a real JIT.
Seeing all of that get bogged down in committee bureaucracy now is just frustrating.
I have a lot of respect for the core devs and I know maintaining CPython, and it is a time donation job. It isn't easy. But I feel that over-caution and red tape ends up discouraging serious contributions. They are setting an unreasonably high bar for something that would obviously help the entire ecosystem.
Just think about the sheer amount of electricity and compute power being wasted every single day running inefficient Python across millions of machines worldwide.
Python really deserves a proper JIT. I genuinely hope they reconsider this.
PyPy lacks upstream interest, looked like it could have a shot after many years of development but recently NumPy removed support because they just couldn’t fathom how a non-dead project could be a couple of versions behind CPython.
Now the new JIT is dying because of what seems to be a lack of upstream interest. (The things TFA describes as being required are not unreasonable, but not realistic for a necessarily speculative long-running project without wild amounts of committed funding.)
I’m not optimistic.
IIRC Unladen Swallow was, despite the extreme hype, nothing more than the internship project of a couple of students. It died because their internship was over.
Otherwise you're right, though. Lots of CPython alternatives suffer from lack of upstream interest - the Python language designers don't seem very interested in anything other than CPython. In particular, they appear to only consider CPython when adding features to the language. Two examples:
- Requiring `dict`s to be ordered because that's how they work in CPython, without considering how they work in other implementations
- Adding pattern matching syntax that's suitable for CPython's PEG parser, even though it's not LL(1) so can't be parsed by, say, MicroPython
Every single time I remember the first AI wave was done with Lisp and Prolog, both with tooling that supports machine code generation since about 50 years.
That's what's kept the language and ecosystem improving and from becoming a hot mess. If something isn't properly specced then it really shouldn't be in prod. They allowed the experiment in the first place so it'd be easier to gather sufficient data to guide said speccing, but the ball was dropped by the proposers and so the experiment was an ultimate failure (unlike free threading) and prod is now being appropriately cleaned up.