Sorry if this comes off negative, but this post reads a bit like a press release to me. It would be nice to state the motivation up front. It seems like almost all the information was available in the launch, e.g. https://news.ycombinator.com/item?id=35790367
i.e. it is basically advertising a language that’s currently only available as a web service after sign-up
No problem and thank you for expressing your thoughts on the post. I’m excited about the language. I did want to write a deeper post but I felt it might be better to write an introductory post and then more detailed articles on specific features of the language.
As per Chris Lattner – they want to build the core of the language before releasing it as open source. This is what he said on Discord when asked about the date of open source:
“I would tell you if I knew 🙂. Our priority is to build the “right thing” not build a demo and get stuck with the wrong thing. My wild guess is that the language will be very usable for a lot of things in 18 months, but don’t hold me to that.
It WILL be open-sourced, because Modular on its own isn’t big enough to build the whole ecosystem Unlike Apple and Swift”
I think the biggest one is the compiler using MLIR for compilation to CPU/GPU/TPU/etc. Mojo exposes MLIR types & dialects, so you could write custom primitive types that target custom hardware and have them available from Mojo (and, in the future, Python code you’re running inside the Mojo interpreter). There are a lot of existing transformations in the MLIR ecosystem they can pickup today, along with whatever custom dialect transformations they’re making in Mojo.
This is killer for tensor/vector operations, and Modular has shown this performance increase accumulates to full programs with their inference engine being 2x-3x faster than TF & PyTorch (on their select benchmarks).
Their goal is to support 100% of Python syntax, so it should be possible to write and run Pure Python code in Mojo.
From what I understand, you will continue to write your Python code in Mojo but the parts which are performance critical you would write in the extended syntax provided by Mojo and use the efficient primitives provided by Mojo such as SIMD, loop unrolling, multi-core execution.
Although, you could do this today in Python as well. For example, by writing the performance critical parts in C, or by using Cython/Numba. But Cython/Numba cannot optimize everything, and the other advantage offered by Mojo is that it can target multiple hardware architectures without any effort on the programmer’s part.
Consider: What structural properties might Mojo have which allows it to do things that Cython, Nuitka, or other prior attempts have failed to do? How will Mojo handle eval and exec, for example? More pointedly, what does Mojo offer that a JIT compiler cannot also offer?
I’m quite excited about mojo. It seems like it will make python the language even more powerful by making it possible to create binaries. I’m curious to see how Modular is going to cultivate the community and choose to monetize it in the long run
I’m sure you can create binaries of Mojo code, but how would it work with Python code? Is that being claimed?
I think there’s been a great deal of confusion over the technical relationship between Mojo and Python.
As stated in their launch docs, Mojo doesn’t even support Python classes. So uh all NumPy objects are instances of classes.
What I saw shown was that you create vectors and matrices with Mojo struct , and then you copy them into NumPy objects to use matplotlib and so forth.
That seems like a good strategy for a fast low level language interacting with a slower dynamic high level one.
But I don’t see a real path to creating binaries from code of the typical stack: Python + NumPy + SciPy + matplotlib, etc.
I think there is going to be the “long tail” issue
With significant effort, you can create a version of Python that looks compatible enough to users writing new code. See Jython, IronPython, PyPy. I’m sure they can do this.
With great effort, write a Python interpreter that can run any pure Python code out there. MicroPython is an example of a useful project that falls short of this (e.g. its Unicode is different AFAIK), but I also think they can do this.
With even greater effort, your interpreter can run some C extensions. See PyPy’s long history with this. Note that Python is only recently getting a stable ABI – in the past you actually would have to emulate CPython 2.6, 2.7, 3.0, 3.1 APIs to run code !! PyPy has parallel releases to match different version of Python.
I think it’s basically an unsolved problem to run even 50% of the important C extensions out there. Is CPython is the only implementation that can run NumPy and Pandas? I think so. And if you add matplotlib and few others, I’m pretty sure it is.
I think you can get to #2 in a few years (although don’t underestimate how hard it is to implement Python classes compatibly !! It is a very big language semantically; the syntax is misleading)
I don’t want to be too negative since Lattner basically achieved the impossible with LLVM / Clang, improving all of open source … but I think 3 and 4 will take a lot longer than people think (if they are even goals, and I think they are).
Higher level can sometimes be harder, because you have more stuff that you sit on top of. Python sits on shakier foundation of things that have more versions than say x86 and ARM, which LLVM sits on.
Also I think doing things within a company could discourage outside contribution and knowledge, which I think is needed. It seems to me like LLVM succeeded in a large part because it was open source and also sponsored by Apple, Google, etc.
One concern I had is that I didn’t hear much mention of them hiring people in the Python community … like NumPy creator Travis Oliphant has his own company and projects around fast Python compilers. I think it would go a lot faster to approach things from both sides – i.e. basically fork NumPy for Mojo and then merge things upstream. But maybe that’s already happening and I don’t know, or they will quickly change strategies to something like that.
Their current solution to run Python code (from my understanding) is exactly like how Julia / Swift bridging to Python: running Python code in CPython interpreter and then bridging through CPython API. It works (I maintain my own fork of PythonKit for Swift, which owes it’s origin from S4TF project), but to go deeper, 1. you cannot make Python go faster; 2. the bridging of custom types such as numpy ND-array, PyTorch’s tensor would still take effort and not automatic; 3. it restricts the host language choices such as refcount over garbage collect (this is easier since Mojo is a new language and aim to have familiar syntax as Python).
Right, this is basically exactly what I was trying to say
I don’t know the details, since the project isn’t public
But everyone is thinking they ALREADY wrote a superset of Python. But what they appear to have done is
Wrote a small, fast, static language with Python syntax, and with a runtime bridge to CPython
SAID they would make it a superset in the future
There’s a huge difference between those 2 things. I’m not saying they can’t do that, or won’t do that – I just want to know what it is, without being clouded by marketing. I have huge respect for accomplishments of the Modular team, but the way it was presented was pretty confusing.
(And this substack post certainly didn’t help with that!)
They have their own standard library implantation and their own compiler. It basically supports python language features plus some new syntax for new capabilities like static types
Mojo still doesn’t support classes, the primary thing Python programmers use pervasively! This isn’t because we hate dynamism - quite the opposite. It is because we need to get the core language semantics nailed down before adding them. We expect to provide full support for all the dynamic features in Python classes, and want the right framework to hang that off of.
Having a Python compatible standard lib means you can run your Python code as is via mojo without changing it.
Some python libs would need to be ported over to mojo. If it becomes popular, I’m sure that all happen. If they keep the language and the tools open source, i think it would help become popular. We’ll see..
Btw I don’t think they will ever do #3 or #4. Mojo isn’t trying to be a better Python. It’s using python as a stepping stone because it’s a popular language, especially for ai/ml.
Yes, they have definitely got the attention. It seems promising, although in order to get the max performance we do need to step outside of the Python syntax and use Mojo’s extended syntax but that is the case in Python as well – you would write C/C++ or Cython code. The advantage here is that the same Mojo code will run on every hardware without any changes.
As far as monitization is concerned, I think Modular might leverage their platform such as the AI inference engine and other offerings. Mojo, they are going to opensource at some point.
Sorry if this comes off negative, but this post reads a bit like a press release to me. It would be nice to state the motivation up front. It seems like almost all the information was available in the launch, e.g. https://news.ycombinator.com/item?id=35790367
i.e. it is basically advertising a language that’s currently only available as a web service after sign-up
No problem and thank you for expressing your thoughts on the post. I’m excited about the language. I did want to write a deeper post but I felt it might be better to write an introductory post and then more detailed articles on specific features of the language.
Have they directly stated if Mojo is going to be open source or not, or set expectations for when that first open source release might happen?
I love it on paper, but if it’s not open source I’m not going to commit any time to trying it out.
As per Chris Lattner – they want to build the core of the language before releasing it as open source. This is what he said on Discord when asked about the date of open source:
“I would tell you if I knew 🙂. Our priority is to build the “right thing” not build a demo and get stuck with the wrong thing. My wild guess is that the language will be very usable for a lot of things in 18 months, but don’t hold me to that.
It WILL be open-sourced, because Modular on its own isn’t big enough to build the whole ecosystem Unlike Apple and Swift”
https://mojodojo.dev/mojo_team_answers.html#date-to-open-source
How is this different from other dialects of Python which compile a subset to fast native code?
I think the biggest one is the compiler using MLIR for compilation to CPU/GPU/TPU/etc. Mojo exposes MLIR types & dialects, so you could write custom primitive types that target custom hardware and have them available from Mojo (and, in the future, Python code you’re running inside the Mojo interpreter). There are a lot of existing transformations in the MLIR ecosystem they can pickup today, along with whatever custom dialect transformations they’re making in Mojo.
This is killer for tensor/vector operations, and Modular has shown this performance increase accumulates to full programs with their inference engine being 2x-3x faster than TF & PyTorch (on their select benchmarks).
Their goal is to support 100% of Python syntax, so it should be possible to write and run Pure Python code in Mojo. From what I understand, you will continue to write your Python code in Mojo but the parts which are performance critical you would write in the extended syntax provided by Mojo and use the efficient primitives provided by Mojo such as SIMD, loop unrolling, multi-core execution.
Although, you could do this today in Python as well. For example, by writing the performance critical parts in C, or by using Cython/Numba. But Cython/Numba cannot optimize everything, and the other advantage offered by Mojo is that it can target multiple hardware architectures without any effort on the programmer’s part.
Consider: What structural properties might Mojo have which allows it to do things that Cython, Nuitka, or other prior attempts have failed to do? How will Mojo handle
evalandexec, for example? More pointedly, what does Mojo offer that a JIT compiler cannot also offer?I’m quite excited about mojo. It seems like it will make python the language even more powerful by making it possible to create binaries. I’m curious to see how Modular is going to cultivate the community and choose to monetize it in the long run
I’m sure you can create binaries of Mojo code, but how would it work with Python code? Is that being claimed?
I think there’s been a great deal of confusion over the technical relationship between Mojo and Python.
As stated in their launch docs, Mojo doesn’t even support Python classes. So uh all NumPy objects are instances of classes.
What I saw shown was that you create vectors and matrices with Mojo
struct, and then you copy them into NumPy objects to use matplotlib and so forth.That seems like a good strategy for a fast low level language interacting with a slower dynamic high level one.
But I don’t see a real path to creating binaries from code of the typical stack: Python + NumPy + SciPy + matplotlib, etc.
I think there is going to be the “long tail” issue
I think you can get to #2 in a few years (although don’t underestimate how hard it is to implement Python classes compatibly !! It is a very big language semantically; the syntax is misleading)
I don’t want to be too negative since Lattner basically achieved the impossible with LLVM / Clang, improving all of open source … but I think 3 and 4 will take a lot longer than people think (if they are even goals, and I think they are).
Higher level can sometimes be harder, because you have more stuff that you sit on top of. Python sits on shakier foundation of things that have more versions than say x86 and ARM, which LLVM sits on.
Also I think doing things within a company could discourage outside contribution and knowledge, which I think is needed. It seems to me like LLVM succeeded in a large part because it was open source and also sponsored by Apple, Google, etc.
One concern I had is that I didn’t hear much mention of them hiring people in the Python community … like NumPy creator Travis Oliphant has his own company and projects around fast Python compilers. I think it would go a lot faster to approach things from both sides – i.e. basically fork NumPy for Mojo and then merge things upstream. But maybe that’s already happening and I don’t know, or they will quickly change strategies to something like that.
Their current solution to run Python code (from my understanding) is exactly like how Julia / Swift bridging to Python: running Python code in CPython interpreter and then bridging through CPython API. It works (I maintain my own fork of PythonKit for Swift, which owes it’s origin from S4TF project), but to go deeper, 1. you cannot make Python go faster; 2. the bridging of custom types such as numpy ND-array, PyTorch’s tensor would still take effort and not automatic; 3. it restricts the host language choices such as refcount over garbage collect (this is easier since Mojo is a new language and aim to have familiar syntax as Python).
Right, this is basically exactly what I was trying to say
I don’t know the details, since the project isn’t public
But everyone is thinking they ALREADY wrote a superset of Python. But what they appear to have done is
There’s a huge difference between those 2 things. I’m not saying they can’t do that, or won’t do that – I just want to know what it is, without being clouded by marketing. I have huge respect for accomplishments of the Modular team, but the way it was presented was pretty confusing.
(And this substack post certainly didn’t help with that!)
They have their own standard library implantation and their own compiler. It basically supports python language features plus some new syntax for new capabilities like static types
Yes, but the compiler and stdlib are not for Python – they’re for Mojo
Right now Mojo is a language that links with and talks to Python, and maybe some day will become something like a superset of Python
As mentioned, it doesn’t support classes. Think about how much of the Python standard library you can run without classes – basically zero.
it doesn’t support them yet
source
The goal is explicitly to become a superset of Python
Adding support for classes is on their roadmap
Having a Python compatible standard lib means you can run your Python code as is via mojo without changing it.
Some python libs would need to be ported over to mojo. If it becomes popular, I’m sure that all happen. If they keep the language and the tools open source, i think it would help become popular. We’ll see..
Btw I don’t think they will ever do #3 or #4. Mojo isn’t trying to be a better Python. It’s using python as a stepping stone because it’s a popular language, especially for ai/ml.
Yes, they have definitely got the attention. It seems promising, although in order to get the max performance we do need to step outside of the Python syntax and use Mojo’s extended syntax but that is the case in Python as well – you would write C/C++ or Cython code. The advantage here is that the same Mojo code will run on every hardware without any changes.
As far as monitization is concerned, I think Modular might leverage their platform such as the AI inference engine and other offerings. Mojo, they are going to opensource at some point.