4 ms·

There's also this community wisdom, echoed in the article, that python can't be made fast because the runtime extensible language semantics get in the way. Some

by chubot 3y ago

There's also this community wisdom, echoed in the article, that python can't be made fast because the runtime extensible language semantics get in the way. Somehow that is known to be true despite javascript having the same properties and very fast implementations, and people are still holding onto it as truth after Mojo starts talking about statically compiling the static parts of the program. Also the self and lisp implementations that came before. Python and JavaScript DO NOT have the same properties. It's harder to make Python run faster than to make JavaScript run faster, in general. This is a VERY common misconception. Reasons here: https://news.ycombinator.com/item?id=20953221 https://news.ycombinator.com/item?id=20953221 You can make Python A LOT faster if you change the semantics so it's not Python, but instead a language that looks like Python with different behavior. I did that with 4000 lines of code on top of MyPy's typed AST, in Oils: https://www.oilshell.org/blog/2022/05/mycpp.html https://www.oilshell.org/blog/2022/05/mycpp.html It's faster than v8, SpiderMonkey, and basically any Python compiler. Because you just cheat and change the semantics so they're fast. We run exactly 1 program. The real problem is running arbitrary code, and that's again harder for Python than JavaScript, and it takes closer to 1M lines of code, not 4000. --- This is sort of what Mojo has done, which is another thing that seems to be widely misunderstood. They did NOT write a compiler for arbitrary Python code. They stated they WOULD achieve full compatibility with Python, but that hasn't been done yet. They wrote a fast compiler for a language with Python-like syntax, but different semantics. (But not even that, because it's fn and struct rather than def and class). And then they made a runtime bridge from that language to the stock CPython interpreter, similar to how Swift has some CPython integration for machine learning. It's better to think of static Mojo as a Swift-like language with Python syntax. It's NOT Python -- the syntax is not what matters; the semantics are what matter. --- My initial impressions, based on knowledge of Python, but before Mojo was released: https://lobste.rs/s/nppf8y/mojo_is_much_better_objective_c_without_c#c_ufrzhc https://lobste.rs/s/nppf8y/mojo_is_much_better_objective_c_w... https://lobste.rs/s/qbcjsl/mojo_future_ai_programming#c_a5vgqv https://lobste.rs/s/qbcjsl/mojo_future_ai_programming#c_a5vg...

JonChesterfield 3y ago
The most common belief is that python is intrinsically very hard to execute efficiently. Which seems valid. However there's a conclusion drawn that it must therefore always be slow. Your link has some of the usual points but seems to miss the global interpreter lock which usually attracts blame. Nevertheless, I maintain that python and javascript are semantically the same thing in terms of the properties that make ahead of time compilation hard. Basically that stuff changes on you at runtime and the type system can express things that static ones cannot. So you have to do the assume + jit + rollback game for either of them, at which point python might have a longer list of stuff that is assumed constant in the prelude. But then I'm not going to write a proof of this - I'm not confident I have enough life left to clone v8 for python, nor do I have motivation to do so. I expect mojo will end up serving that role. It doesn't have the same semantics yet, but that's the stated goal and I think they'll get there.
- chubot 3y ago
  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.
  - JonChesterfield 3y ago
    One of the flaws of the comment format is brevity mixed with a tendency to write conclusions without the reasoning behind them. Mojo is an extension of python. In addition to the existing syntax, there are new keywords to opt into a more static set of semantics, chosen to compile directly to efficient code. You can have a machine integer instead of an arbitrary size python one, but they have different names. This gives you a path to writing code which doesn't opt into pythons compilation challenges. Or you can compile raw python as-is, but you get whatever type inference it manages, and some things aren't implemented yet. It also has calls into cpython for some stuff, but that's not inherent to the implementation strategy and I hope will not last forever. This is personally interesting because it takes the python + C extension model, and the adjacent C++ that shows up nearby, and reassembles the semantics under a single compiler stack which has a credible path to optimising across the combination. This is perilously close to what I want a programming language to be, possibly to the extent that I'm assuming they're going to do the obviously correct things in the future, so I would be interested to hear if any of the above is disjoint from your understanding. It may mean I need to recheck that they've built what I think they have.

by chubot 3y ago

JonChesterfield 3y ago

The most common belief is that python is intrinsically very hard to execute efficiently. Which seems valid. However there's a conclusion drawn that it must therefore always be slow. Your link has some of the usual points but seems to miss the global interpreter lock which usually attracts blame. Nevertheless, I maintain that python and javascript are semantically the same thing in terms of the properties that make ahead of time compilation hard. Basically that stuff changes on you at runtime and the type system can express things that static ones cannot. So you have to do the assume + jit + rollback game for either of them, at which point python might have a longer list of stuff that is assumed constant in the prelude. But then I'm not going to write a proof of this - I'm not confident I have enough life left to clone v8 for python, nor do I have motivation to do so. I expect mojo will end up serving that role. It doesn't have the same semantics yet, but that's the stated goal and I think they'll get there.

chubot 3y ago
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.
- JonChesterfield 3y ago
  One of the flaws of the comment format is brevity mixed with a tendency to write conclusions without the reasoning behind them. Mojo is an extension of python. In addition to the existing syntax, there are new keywords to opt into a more static set of semantics, chosen to compile directly to efficient code. You can have a machine integer instead of an arbitrary size python one, but they have different names. This gives you a path to writing code which doesn't opt into pythons compilation challenges. Or you can compile raw python as-is, but you get whatever type inference it manages, and some things aren't implemented yet. It also has calls into cpython for some stuff, but that's not inherent to the implementation strategy and I hope will not last forever. This is personally interesting because it takes the python + C extension model, and the adjacent C++ that shows up nearby, and reassembles the semantics under a single compiler stack which has a credible path to optimising across the combination. This is perilously close to what I want a programming language to be, possibly to the extent that I'm assuming they're going to do the obviously correct things in the future, so I would be interested to hear if any of the above is disjoint from your understanding. It may mean I need to recheck that they've built what I think they have.