GraalPy and PyPy are great technology achievements, the problem is that the Python community at large rather prefers their C bindings or nowadays Rust, sprinkle a bit of Python FFI on top, and call them "Python" libraries.

▲

famouswaffles 2 hours ago | parent | next [-]

>the problem is that the Python community at large rather prefers their C bindings or nowadays Rust, sprinkle a bit of Python FFI on top, and call them "Python" libraries.

They are Python libraries. Don't make the mistake of screwing up the cause and effect here. C, Rust etc - those are the replaceable parts of the chain. There is an official C++ pytorch library and virtually nobody uses it for ML Research. People want to code in python and build those libraries so they can.

	▲	pjmlp 4 minutes ago \| parent [-]
		Nope, they are Python bindings to native libraries. PyTorch in C++ naturally gets little use, because most people don't want to use C++, and although possible, e.g. CINT, very few care about C++ REPLs. Also these libraries only exist because Python cannot deliver on its own, like Lisp or Scheme, and needs such libraries in first place. Even BASIC has better options to do machine code and system programming than Python, starting with the original Dartmouth BASIC.

▲

mike_hearn 2 hours ago | parent | prev [-]

Yes, well, even with fancy JITs Python will never be a speed monster. Interop with libraries written in Java can be very high performance though as Pyronaut shows. And the heavy lifters that are hard to replace like NumPy and PyTorch do work with GraalPy.

I think if the Python community wants an implementation that has a proven JIT and where the remaining work is easily scaled compatibility testing, then there's one available and ready. Whether they're calling into C or Rust or FORTRAN or Java shouldn't make a big difference in principle.

Now, I've met lots of people who think that binding to Rust will always be the fastest thing to do but that underestimates Java significantly, especially once you factor in the fact that GraalPy can optimize out interop overheads.

Consider LLM tokenization. It's one of the most heavily optimized pieces of code on the planet. Yet, toknroll written in Java can beat tiktoken which is written in Rust:

https://github.com/qxoticai/qxotic/tree/main/toknroll

Moreover the Rust code has some unsafe{} blocks as Rust often does, whereas toknroll has no unsafe code anywhere.

So the scripting language communities need to think hard about where they go next, IMHO. DHH already got up and announced at a Rails conference that Ruby is over, you should use Rust for everything. I don't think that's quite true, but it's going to be a meme that with agents you should just pick the fastest language and go. If Python/Ruby/etc want to stay relevant then they need to care a lot more about their performance story. Just being more pleasant to read and write for humans doesn't cut it anymore. CPython is clearly not going to happen in this regard, so alternative implementations need to start being taken a lot more seriously than they were in the past.