upvote

points

by necovek17 hours ago |
comments
upvoteby xorcist16 hours ago|
next
[-]
> The type of dynamic language gymnastics done with Python is huge

Have you seen Ruby?

reply
upvoteby KerrAvon11 hours ago|
parent|
[-]
Ruby is essentially Smalltalk (see also Objective-C).

I don't know Python's innards well enough to understand why it's so especially difficult in this regard, but I gather around the edges that its object model may not be as well founded.

reply
upvoteby jashmatthews9 hours ago|
parent|
[-]
JIT compiling Ruby or Python in a way that speeds up code using existing libraries and frameworks is harder. We built up decades of code that does stuff that it would be a lot easier for JIT performance if we didn't do, like using C extensions instead of defined FFI.

https://arxiv.org/html/2609.01502v1

reply
upvoteby pjmlp14 hours ago|
prev|
next
[-]
The common excuse that ignores Smalltalk, Self, Lisp Machines like Interlisp-D, and more recently Ruby.

All just as dynamic as Python, and with quite usable JIT compilers.

Or for that matter, PyPy and GraalPy do exist.

reply
upvoteby necovek11 hours ago|
parent|
[-]
Obviously, I am not saying making a JIT for Python is impossible: both PyPy and GraalPy prove otherwise. We are talking about full ecosystem support, not just the base language and stdlib.

Can you just replace CPython with PyPy or GraalPy in every project? And why not? :)

reply
upvoteby pjmlp1 hours ago|
parent|
[-]
Because the Python community writes libraries in C, C++, Fortran and Rust, to make up for the CPython slowness, using CPython C API, calls them Python libraries, and they naturally only work in CPython.

PyPy and GraalPy then never get to use those pseudo "Python" libraries, because their API for C based extensions differs enough that you cannot take a random shared library and load them into either.

They came up with a common C API proposal, but has hardly taken that much adoption.

reply
upvoteby necovek40 minutes ago|
parent|
[-]
Indeed, mixing all the language features and anti-features with non-native Python libraries is a big reason too — both because it mitigates many of the performance issues a JIT would solve, but mostly because it complicates or makes the implementation unfeasible altogether.
reply
upvoteby cyberax16 hours ago|
prev|
next
[-]
Operator overloading is a non-issue, it's just another form of method calls.

JavaScript also has monkey-patching, and it's also very common. E.g. SolidJS replaces objects with dependency-tracking proxies.

There are really no fundamental language reasons why Python should be more complex. From what I heard from a JIT developer, the main issue is not the code itself but the module system and code loading.

JavaScript was designed from the start to operate inside a sealed environment with only few external handles, with the code loaded upfront or added on-demand via "eval". Not so for Python, where native code modules can (and will) result in code loaded dynamically and it's hard to track what depends on what.

reply
upvoteby pjmlp14 hours ago|
parent|
next
[-]
See Self and Smalltalk for such kind of highly dynamic environment with code being loaded, and completely changing the running image on the fly.

Yet both languages are on the genesis of modern JIT compilers, going beyond what was already being done for Lisps, Prolog, BASIC.

reply
upvoteby exyi10 hours ago|
parent|
prev|
[-]
> JavaScript also has monkey-patching, and it's also very common. E.g. SolidJS replaces objects with dependency-tracking proxies.

And the proxies make it slow as Python. Plain objects cannot suddenly become proxies, so the runtime can treat them as a special case.

reply
upvoteby mistrial97 hours ago|
prev|
[-]
> Many libraries depend on monkey-patching live library calls, including ones to external dependencies

someone please think of the monkey patchers!

reply