Hacker News Reader

JITs for Javascript aren't comparable; at the time, nobody had C-based extensions for Javascript. It makes it a radically simpler problem.

Remove the "maintaining compatibility for C-based extensions" requirement, and you get, well, PyPy. And you also get a community split that makes 2/3 look trivial. Vast swathes of core Python code and libraries are really not "Python", but Python C-based bindings to custom code or C libraries.

View on HN

Sure there were C-based extensions for JavaScript, that's how it integrates with the DOM. It makes it a little trickier but not a whole lot.

Sorry, perhaps I was unclear. I mean, there were no C-based extensions not under the control of the same project as controlled the JS engine, so one entity can both JIT a JS engine and simultaneously make whatever modifications it took to make them work under the new engine. Python has an enormous amount of external C-based extensions not controlled by any one entity, which constitute huge swathes of core (in importance, not in "under control of the core team") Python libraries. It's difficult to imagine what a JIT looks like that still works with those. You don't have one entity doing both the JIT and all the C extensions.

Reply on news.ycombinator.com