[–] bunderbunder 2 days ago
[–] cogman10 2 days ago
The scope of a JIT is the entire python runtime. Not at the beginning, it can be more narrow, but certainly it can evolve to cover everything. JITs touch everything.
> success criteria
Impossible to measure. JITs don't universally make things faster and unless the SC was willing to accept "some programs will see around x% improvement" then it would be impossible to actually give them the criteria they want. There's a reason C++ compilers and their optimizations aren't defined by the ISO committee.
> support plan
Like most JITs, support for a JIT is an ongoing and ever evolving process. What's needed depends entirely on what's needed today. You usually need more than 1 or 2 dev working on it, which may be the issue here.
> It’s just that open-ended experimentation doesn’t belong in main, of all places.
Very strong disagree. That's simply the nature of performance optimizations for JITs. They belong on main because new optimizations and heuristics will always be generated. The role of doing a compiler is a long term experiment in performance, seeing what your runtime is currently doing and how it's being used and tweaking it to work better.
pypy isn't in a worse place because it's been running a longterm performance experiment.
> They have an ongoing duty to ensure that a critical piece of global infrastructure remains stable and trustworthy to consider.
None of the things mentioned actually do that, other than perhaps a support plan. There are plenty of critical infrastructure projects who all can manage to develop JITs. Python is the special snowflake that has decided to do JIT development incorrectly.
This is a runtime optimization/implementation detail. It's foolish to send it through a committee approval process. That's why you won't be able to find a single language with a JIT or advanced optimizations that has do it by committee.
[–] ModernMech 2 days ago
> This is a runtime optimization/implementation detail.
I view JITs as a critical architectural component. Like you said, it impacts the whole system. Optimization and implementation details don't usually do that.
[–] vlovich123 2 days ago
[–] bunderbunder 2 days ago
It’s kind of wild how nice Python’s C extension system, which enables basically zero cost interop with native code, is for certain purposes. It supports a situation that’s comparable to the games industry’s tradition of putting a Lua or Lisp tip on top of a C++ iceberg.
[–] jeremyjh 1 day ago
Who is this a problem for?
I think there is enough evidence to conclude that most language ecosystems cannot support multiple implementations that are fit for general purpose usage. There are almost no successful examples, and there are many, many failures.
The most successful things I can think of:
C & C++ - often does require at least some pre-processor logic or different build system settings.
Java - I'm not 100% sure - I think there are credible implementations of both the JVM and compiler though of course almost everyone is building from the openjdk or the commercial fork.
Nodejs & Bun - Most of NPM just works.
...
Thats it. Honorable mentions like C#/Mono exist, but if you look at that ecosystem a majority of applications only ever built with one of those, not both.
There are niches maybe like some subsets of scheme or common lisp - but I think most apps have a single implementation creating the builds that they ship. There are re-implementations perhaps that would count that I don't know enough about like Delphi/Lazarus, but I truly don't think there is another mainstream example.
In Haskell, SPJ noted years ago that GHC was really the reference implementation and he no longer considered standards work to be worthwhile (though it has continued past that).
Others I think have reach the same conclusions, such as Ruby. I could be missing something but I don't think most platforms should even aspire to support this.
[–] bunderbunder 2 days ago
Perhaps these priorities were always irreconcilable.
Perhaps that’s why the existence of competing Python JIT projects that weren’t trying to commit directly into CPython’s main branch kept coming up in the conversation.
[–] jeremyjh 2 days ago
The experiments had long been done. The topic at hand was including it as a core feature.
As they themselves pointed out, the problem isn’t that there’s anything wrong with an open-ended experiment. It’s just that open-ended experimentation doesn’t belong in main, of all places. They have an ongoing duty to ensure that a critical piece of global infrastructure remains stable and trustworthy to consider.