Creating a new language in the age of AI seems kind of pointless. I don't write code by hand anymore, I only review it and I prefer it to be in a language which I already know since investing time in learning another language doesn't make sense at this point.
> Finally, we will continue to progressively open-source more of the Mojo language, as well as components in MAX that we have built with it. Our commitment remains unchanged – we will open source the Mojo compiler and toolchain in 2026.
Why not now though? Why wait for 4 more months? What magic is there to hide in just making it source available at least.
I feel like this language would really benefit from some sort of 1-pager overview.
I just spent a fair bit of time on the official site, and I still don't think I have a very good grasp of what problem this language aims to solve, or why I would select it over other similar languages
To be fair, a good bit of the apps/programs/projects posted on hacker news could use a good '1-pager overview'. Like has nobody every explained the 'elevator pitch'. A little marketing doesn't mean you are selling out. Obfuscating your product doesn't make you hip.
You may compile, linking binary libraries compiled with different versions is a different matter, especially if there are relevant changes between versions on either the standard library, or other dependencies.
Is Mojo being a superset of Python still part of its projected feature set?
I tried Mojo a bit early on and decided to come back to it when it was more complete, and in the interim I read some comments somewhere that the superset-of-Python part was being walked back from.
On https://mojolang.org/docs/roadmap/ it's stated (Phase 3) that "Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't."
I feel like that "full superset of Python" part was part of the appeal of Mojo.
Personally I'm kind of tired of 97% python-compatible this-and-that. Python itself has enough of a history of incompatibility and the cognitive overhead in switching might be easier with just moving to a totally different language. But maybe not — it depends on the details I guess.
Honestly reading through the documentation more and more I'm more and more confused about what the 1.0 release actually means.
Nothing but respect for Chris, and I understand why founders take these deals. But an acquihire usually means the product is the part that gets left behind, and that's the part I cared about.
I wish Modular/Qualcomm good luck with this. We would be well served with a good alternative to Cuda. I will be looking at Modcon to see how serious they are with Mojo's ecosystem. (Hopefully it won't be yet another SYCL).
From Mojo Wikipedia article:
```
The intention behind Mojo is to bridge the gap between Python’s ease of use and the fast performance required for cutting-edge AI applications.
```
Mojo and Julia have some very fundamental differences though...
Mojo is a fully ahead-of-time (AOT) compiled systems language. Julia is much more dynamic, and its AOT compilation story is still quite weak. Mojo also has explicit memory management, unlike Julia and its real time unfriendly garbage collector.
Mojo also has the concept of ownership, similar to Rust, while Julia does not.
Mojo is being pitched as an efficient, general purpose, Pythonic systems language which can target a variety of hardware types. That seems like a good target to me, I hope it's successful!
One thing to keep an eye on is whether or not a Windows port emerges after it's open sourced...
(A) Mojo is intended to be a more ergonomic Rust, with Pythonic syntax, and much faster compilation.
(B) Mojo supports multiple GPU types, including AMD, Apple, and whatever may come along. That's one of its major selling points over CUDA. It's also targeted at other novel hardware accelerators etc.
38 comments
[ 0.22 ms ] story [ 14.5 ms ] threadAm I understanding the current state of things correct?
Much better options out there. Python already has libraries like Pydantic that offload performance to functions written in Rust under the hood.
But I hope they succeed, it's a very interesting approach. Then I will jump on it later on. S
They should show some performance comparisions between PyTorch and Mojo, PyTorch+kernel compilation + Triton vs Mojo, ThunderKittens vs Mojo.
Lastest OpenCV 5 release notes also had a lot of LLMisms.
I guess that's the new normal. Still, I am very hopeful for Mojo.
Why not now though? Why wait for 4 more months? What magic is there to hide in just making it source available at least.
I just spent a fair bit of time on the official site, and I still don't think I have a very good grasp of what problem this language aims to solve, or why I would select it over other similar languages
awesome
This gave me a chuckle. When I think of languages evolving their standards, I do think of C++. But not, you know, in a good way.
I tried Mojo a bit early on and decided to come back to it when it was more complete, and in the interim I read some comments somewhere that the superset-of-Python part was being walked back from.
On https://mojolang.org/docs/roadmap/ it's stated (Phase 3) that "Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't."
I feel like that "full superset of Python" part was part of the appeal of Mojo.
Personally I'm kind of tired of 97% python-compatible this-and-that. Python itself has enough of a history of incompatibility and the cognitive overhead in switching might be easier with just moving to a totally different language. But maybe not — it depends on the details I guess.
Honestly reading through the documentation more and more I'm more and more confused about what the 1.0 release actually means.
But mojo is a superset, not a subset. So why not use a subset, infer what you need and generate mojo?
I've never seen this question actually presented to the company and discussed in more detail.
Basically, same raison d'etre as that of Julia.
Mojo is a fully ahead-of-time (AOT) compiled systems language. Julia is much more dynamic, and its AOT compilation story is still quite weak. Mojo also has explicit memory management, unlike Julia and its real time unfriendly garbage collector.
Mojo also has the concept of ownership, similar to Rust, while Julia does not.
Mojo is being pitched as an efficient, general purpose, Pythonic systems language which can target a variety of hardware types. That seems like a good target to me, I hope it's successful!
One thing to keep an eye on is whether or not a Windows port emerges after it's open sourced...
python superset would have been perfect.
I do hope the language thrives and gets a community.
All the best to the modular team.
(B) MOJO should should have used Nvidia.
(B) Mojo supports multiple GPU types, including AMD, Apple, and whatever may come along. That's one of its major selling points over CUDA. It's also targeted at other novel hardware accelerators etc.