Python is considerably more dynamic than JavaScript. And I'm not trying to drag pypy, just saying that that's already the state of the art and there are good reasons that the authors of pypy didn't set out to do what Mojo apparently claims to have done.
Take a look at the PyPy FAQ. They're using annotations, type inference assumptions, and so on. PyPy seems to be focused on a Jit-able subset of Python. It's not a project that can one day be transparently included in the new Python release.
JavaScript and Python are not that dissimilar. So we see similar results with JavaScript. People want performance, so a lot of projects are started where people attempt to JIT JavaScript - but in the 14 or so years of JS's existence JavaScript is still several orders of magnitude slower than less dynamic languages. Java and C# have never been as slow as JavaScript is today. Will JIT-ing JavaScript help? Sure. But -great- results? I wouldn't go that far.
I think that is not a really fair comparison, Python with PyPy is pretty fast. Actually I would like to see a comparison for Python on PyPy vs JS in IonMonkey/V8.
There was just a higher incentive to optimize Javascript as it was pretty slow to begin with and was exposed to a lot more users (in the sense that it runs on clients rather than servers) than Python, Ruby and Perl
I'd love to hear more about their issues with PyPy, it sounds like they wrote of PyPy simply because they don't understand why it works so well. Not to mention that this is mostly a re-hash of stuff found in unladen-swallow.
I mean, if your end goal is to write another Python, sure go for it. But it really sounds like these people haven't done their research. I see nothing to write home about.
--- EDIT ---
Not to mention that JS is a completely different language form Python. Everytime you add two objects in Python you have the possibility of hitting a system defined add, or __add__ or __getattr__ or __getattribute__, or __radd__, or __getattr__ (looking for __radd__), etc. That'll be fun....
That's not Node - that's V8. And it's possible to do the same thing for Python - there's nothing magic about JavaScript compared to Python - it's just a lot of engineering work to do it, which is beyond what this project's scope is. PyPy does it, but not inside standard Python.
I agree with Mike Pall's view. And the current crop of Javascript engines proves that too. Simplicity wins over complexity.
Although I still hope pypy will deliver on its promisses. We have to bear in mind that pypy's goal is not just enhanced speed. Its goals are much broader and this is one reason why, perhaps, this is not the best approach if you want full speed (there are trade offs which seem acceptable considering all the other benefits, such as easier of implementation of dynamic languages on top of pypy's framework).
But we're not talking about some optional feature you can just shim in 1kb of JavaScript, we're talking about the language used to write a web app. Sure, you could use PyPy.js as a fallback, but you'd essentially create a horrible loading experience for >99.99% of your users while you wait for this addon to catch on (which won't happen, because there's no reason for an end-user to install it). For a language like Python to be natively supported on the web, at least one major browser has to support it. And that's not likely to happen given the current state of affairs.
Because Python doesn't have the performance of any JVM implementation (not counting toy ones here), not even via PyPy, and JavaScript lacks the tooling, performance of static typing and good support for parallel programming.
I maintain that python and javascript are semantically the same thing in terms of the properties that make ahead of time compilation
With respect, this attitude goes back at least 15 years, and usually comes from compiler people who don't understand Python very well, and the way people use it to solve problems in context.
The problem is very well studied, and your comments indicate that you haven't studied the prior art -- PyPy, Unladen Swallow, Jython/IronPython, Pyston, more recently Cinder and Skybison -- which are DIRECTLY from the v8 lineage.
---
To be clear, what I'm saying is that it's certainly possible to make a v8-like implementation for a Python-like language.
But the "like" is doing a lot of work there, and is the difference between the language being practical, and not practical.
So I think you're a compiler person who has an image of "Python" in his head, which is not Python.
That's not really a knock, because everybody who has tried to optimize Python starts from that position. I think even the Mojo team is, and they know way more about compilers than me -- but less about Python.
My guess is that they will succeed at producing something very interesting and useful in 5-10 years, but either renege on the Python compatibility promises, rewrite NumPy/Pandas themselves, or maintain a bridge to stock CPython forever.
Although I also think your comments indicate a fairly big misunderstanding of what Mojo is.
Python in the browser so far is a big disappointment. I still find it a lot easier to just split frontend and backend development. In the future, PyPy.js might become a viable alternative for big browser applications.
Python is orders of magnitude slower than JS, though. It has the same problems, but doesn't even try solving most. PyPy would be a better VM to compare against.
Things to consider. Javascript has a much stronger separation between language specification, standard library, and runtimes than Python. The Javascript standard library is famously sparse, and there are multiple runtimes with significant usage and development. Python on the other hand has a much larger standard library to maintain, and effectively has only one runtime (yes, I love PyPy too, but realistically 99+% of runtimes are CPython). And they are all implemented by the same group.
The mechanics of quickly releasing language level changes, or standard library changes, or runtime changes in Python I feel do not fully map to that of the Javascript experience.
The language usage models are also very different. In the majority of Javascript use cases, I feel that you either fully control the runtime and code (like in a server, or something like Electron), or you have a fairly intelligent server determining what the runtime environment is and providing backwards compatibility shims for you (polyfills on browsers).
Certainly something like the first case exists for Python, but certainly the tooling for deploying onto arbitrary runtime and capabilities doesn't quite exist. Indeed, the Python packaging story is one of its weaknesses right now.
Python certainly could be made into something where the Javascript like process would work, but I'd certainly agree with anyone in the core Python development team who believed that they thought their energies could be focused better on other priorities.
If you neglect some of the metaclass stuff, which I believe most people do, then Python is nearly isomorphic to JavaScript. I think the comparison is very fair.
I also believe the reason Python is unlikely to ever catch up to JavaScript is the same reason that CPython will always be the dominant implementation - They've exposed so much of the C internals, that everyone is bound to the actual slow and single threaded implementation. JavaScript implementations in web browsers can do lots of magic behind the curtains because the majority of users don't rely on the actual innards being consistent from release to release.
I'm well aware of V8 and pypy. I also really like Python as a language, especially with mypy.
It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API).
There is a really important (if not "magic") difference between JavaScript and Python. JS has always (well, since IE added support) been a language with multiple widely-used implementations in the wild, which has prevented the emergence of a third-party package ecosystem which is heavily tied to one particular implementation. Python on the other hand is for a large proportion of the userbase considered CPython, with alternate implementations being second class citizens, despite some truly impressive efforts on the latter.
The fact that packages written in JS are not tied to (or at least work best with) a single implementation is also what made it possible for developers of JS engines to experiment with different implementation approaches, including JIT. While I'm not intimately familiar with writing native extension modules for Node (having dabbled only a little), my understanding is the API surface is much narrower than Python, allowing for changes in the engine that avoid breaking APIs. But there is less need for native modules in JS, because of the presence of JIT in all major engines.
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.
The thing about Javascript is it's actually a very simple language. You can make a lot of guarantees and this means performance patterns can be implied.
Ultimately JS can be reduced to a very tight engine. This is not possible with Python, it's just too dynamic.
reply