Hacker News Reader

Comment by cs702 | Hacker News Reader

Well, I'm blown away.

If this succeeds, it will allow you to use Python for the entire AI stack: high-level model composition (as usual), fast compiled CPU code (instead of, say, libs written with C++), and on-device operations (instead of, say, libs that use CUDA). Oh, and it will make your Python code parallel (i.e., there's no GIL).

Obviously, we'll have to wait until Mojo is production-ready, but I'm excited after seeing Jeremy Howard's easy-to-follow examples during the live keynote presentation. Jeremy, who sometimes hangs out on HN, must have been dying to tell the world about this for a long while.

Props to the Mojo team!

View on HN

>>If this succeeds, it will allow you to use Python for the entire AI stack [...]

If this succeeds, the terminal endpoint will be the Python Software Foundation adopting Modular as the defacto and eventually official implementation since, as Modular noted in their docs, they effectively need Mojo to be absolutely amazing on generalized host CPUs as the key enabler allowing for the unified Python-superset experience across other types of general and specialized hardware ("xPU").

Julia will be dealt an adoption setback proportional to Mojo's growing success.

No it won't. The language is not a super-set of Python, its another language that somewhat resembles Python. You can't drop in some Python code and run it with Mojo and expect it to work.

The goal is for the language to be a superset of Python

> Further, we decided that the right long-term goal for Mojo is to provide a superset of Python (i.e. be compatible with existing programs) and to embrace the CPython immediately for long-tail ecosystem enablement.

https://docs.modular.com/mojo/why-mojo.html

But see the section "Intentional differences from Python", which is after your quote,

https://docs.modular.com/mojo/why-mojo.html#intentional-diff...

> our approach to compatibility is two fold:

> 1. We utilize CPython to run all existing Python3 code “out of the box” without modification and use its runtime, unmodified, for full compatibility with the entire ecosystem.

> 2. We will provide a mechanical migrator that provides very good compatibility for people who want to move Python code to Mojo.

> Together, this allows Mojo to integrate well in a mostly-CPython world, but allows Mojo programmers to be able to progressively move code (a module or file at a time) to Mojo. This approach was used and proved by the Objective-C to Swift migration that Apple performed.

Maybe the long-term goal is to try to make it a true superset, but it sounds like the detailed plan is more practical, to basically provide a "Python-next" language, like Swift for Objective-C.

Isn't

>We utilize CPython to run all existing Python3 code “out of the box” without modification

from the docs the direct opposite of what the commentator claimed?

I think this discussion is a bit better if you read the docs:

>We utilize CPython to run all existing Python3 code “out of the box” without modification

This isn’t Python though, right? It’s just a Python-like syntax for a much lower level programming language (sort of like Cython) from my cursory glance? It seems a lot like Rust with a Pythonic veneer, so I would expect it will run into many of the same problems that Rust has (lots of difficulty pacifying the borrow checker)?

The source code is Python (well, a superset of Python), but it's not interpreted and run by the official Python interpreter. Judging by what I've seen so far, it seems Modular has been able to "Rustify+Tritonify" Python code in a way that to me feels... very Pythonic.

Maybe someone can correct me, but I don't think it's a superset of Python--I don't think it will accept existing Python programs and I'm pretty sure you can't do all of the dynamic Python stuff (otherwise you would have to essentially compile/link an interpreter into your binaries giving you these super slow paths that aren't necessarily obvious when reading source code).

> Judging by what I've seen so far, it seems Modular has been able to "Rustify+Tritonify" Python code in a way that to me feels... very Pythonic.

I think it "feels Pythonic" because you're looking at Pythonic syntax. I suspect when you're banging your head against a borrow checker it will feel more like writing Rust. Like I'm pretty sure anything with a borrow checker will have to deal with lifetimes, mutable-vs-immutable references, shared mutability (cell/refcell in rust), etc; I don't know how you "Pythonify" that in any meaningful way?

>We utilize CPython to run all existing Python3 code “out of the box” without modification

>Further, we decided that the right long-term goal for Mojo is to provide a superset of Python

The FAQ states that “Mojo is still early and not yet a Python superset, so only simple programs can be brought over as-is with no code changes.”

I have no idea how to reconcile that with the quotes you provided.

[edit] Ah, it seems you can control things running in a bundled CPython:

    plt = Python.import_module("matplotlib.pyplot")
    fig = plt.figure(1, [width, height], dpi)
    ax = fig.add_axes([0.0, 0.0, 1.0, 1.0], False, 1), "hsv", 0, 0, 1.5)
    ...
    plt.imshow(image)

Exciting stuff indeed, looks like a unified approach to recent developments like (OpenAI) Triton, TVM, OpenXLA, ONNX Runtime, etc. though we'll have to wait for proper benchmarks and compatibility to know how great it is. Also it's a bit of a bummer that the compiler is behind a waitlist for now

> Jeremy, who sometimes hangs out on HN, must have been dying to tell the world about this for a long while

Oh yes!

:-)

I can’t wait to see fast.ai-next in mojo :-)

Reply on news.ycombinator.com