Hacker News

points by Krishansubudhi 2 days ago | 0 comments

I hope it does not lead to performance issues later. Python is already famous for being slower than compiled languages.

Being slower than a compiled language is not saying much for an interpreted language. But it's slower than PHP which is a closer comparison, and PHP has had JIT for six years now.

[–] pansa2 2 days ago

Ruby has the reputation of being a very slow language, but Python has been slower still since Ruby jumped ahead with version 1.9, almost 20 years ago. Ruby also has had far more success with JIT compilers than Python has.

[–] chao- 2 days ago

>Ruby also has had far more success with JIT compilers than Python has.

Ruby is on its third (I think?) JIT now? I'm a little surprised, given Ruby's reputation as a wacky "anything goes" language with a very complex grammar, and it makes me wonder why that is? Does it have to do with the design of the runtime itself more than the language semantics? Or is it more incidental, e.g. many popular ibs are C wrappers, already generates bytecode files, and so on.

[–] byroot 2 days ago

The difference is that Ruby follow the BDFL model, and Ruby's BDFL was willing to allow people to experiment with in-tree development of JITs.

If the Python steering committee isn't willing to do the same, they'll probably won't get a working JIT any time soon. Developing a JIT externally, or even from a branch, is just too hard.

[–] samus 2 days ago

Getting a JIT right is hard work because time spent by the JIT is time not spent doing actual work, and finding the correct tradeoffs is very much an empirical problem.

[–] skeledrew 2 days ago

And PHP is quite the hot mess. Always has been, really. See the security issues over the years, including the most recent for example. Meanwhile I've never seen any serious issues for Python that's triggered mass required fixing. There's something to be said for moving carefully and ensuring things aren't broken to the best of one's ability, which is the SC's purpose.

[–] pjmlp 2 days ago

https://app.opencve.io/cve/?product=python&vendor=python

[–] skeledrew 2 days ago

Are you helping me to prove my point? I see 156 results, with 1 in 2023 and the rest before that. Meanwhile there are 801 results with at least a dozen in 2026 for PHP[0], and we still have 2 more months to go.

[0] https://app.opencve.io/cve/?vendor=php

[–] pjmlp 2 days ago

Hardly, one CVE is enough.

[–] skeledrew 2 days ago

Not at all. I specifically stated "serious issues for Python that's triggered mass required fixing", ie. it was so bad that there were public notices for users to update ASAP. The closest thing I can find is CVE-2022-34265, and that's in Django, not Python itself.

[–] pjmlp 2 days ago

Python is hardly used at PHP scale for Web development.

[–] mahboi 2 days ago

and the biggest one, JS

[–] yxhuvud 2 days ago

It is also slower than any other interpreted dynamic language in wide use.