Mojo 1.0 Beta
mojolang.org130 points by sbt567 15 hours ago
130 points by sbt567 15 hours ago
I know Mojo is aimed at ML, but I'm actually really interested in trying it for game development :)
As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. The last time I booted it up, I tried to do some basic string manipulation just to test stuff out, but spent an hour puzzling out why `var x = 'hello'; print(x[3])` didn't work, and neither did `len(x)` (turns out they'd opted for more specific byte-vs-codepoint representations, but the docs contradicted the actual implementation).
Hopefully they get Mojo to a good place for more general ML, but at the moment it still feels quite limited - they've actually deprecated some of the nice builtins they had for Tensors etc... For now I'll stick with JAX and check in periodically, fingers crossed.
Mojo is cool but I just don't understand the python backwards compat thing. They're holding themselves back with that.
All the flaws I can think of in Kotlin are due to the Java compatibility. They could've made it work here by being more explicit but the way it currently works seems doomed.
I'm pretty sure that they have decided that backwards-compat is not the best path for Mojo. Matter of fact, the following is the _last_ item on the roadmap on the home page:
> Supporting more of Python's dynamic features like classes, inheritance, and untyped variables to maximize compatibility with Python code.
What's more, note how it says "to maximize compatibility" not "to achieve full compatibility."
> All the flaws I can think of in Kotlin are due to the Java compatibility.
All the use of Kotlin in industry are due to Java compatibility. Else there would be ~0% marketshare of Kotlin.
Same story with C and Objective-C, C and C++, JavaScript and TypeScript, Java and Scala, Java and Clojure,.....
Yes the underlying platform they based their compatibility on, is the reason they got some design flaws, some more than other.
However that compatibility is the reason they won wide adoption in first place.
>As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs.
Unless it's open sourced, it's a moot point, as most Python devs wont come anyway.
https://mojolang.org/docs/roadmap/#contributing-to-mojo
> We're committed to open-sourcing all of Mojo, but the language is still very young and we believe a tight-knit group of engineers with a common vision moves faster than a community-driven effort. So we will continue to plan and prioritize the Mojo roadmap within Modular until more of its internal architecture is fleshed out.
I hope they stick to their original promise. And the 1.0 release would be a great time to deliver this.
> We're committed to open-sourcing all of Mojo
Translated from corporatese it means "it will never happen".
This is exactly how the open sourcing of Swift went so I imagine it will be the same.
I'm really not sure that's true.. I can't think of a single Python dev I've worked with who cared about opensource. All they cared about is the language being easy and free to use.
This is a bit ironic, given that people seem to have no problem using CUDA all over the place... Plus they promise to open source with the 1.0 release. We'll see...
CUDA won because AMD and Intel made a mess out of OpenCL, and Khronos had no vision to support anything beyond C99 dialect until it was too late.
Doesn't matter if it was closed, when the alternatives were much worse.
SYCL is the de facto successor to OpenCL that supports higher level languages. So the vision was and is there.
As mentioned, Khronos only changed their mind when it was too late.
I can also recite the whole story, the missteps in OpenCL 2. , OpenCL C++, the OpenCL 3.0 reboot, how SYCL came to, CodePlay only proper available implementation, Intel acquisition of CodePlay and everything else.
I don’t see irony there. We’re locked into CUDA due to past decisions. And in new decisions we don’t want to repeat that mistake.
I think that plan is to open source the compiler with 1.0 which is expected to be this summer. so in ~3-4 months time.
Julia is more mature for the same purposes, and since last year NVidia is having feature parity between Python and C++ tooling on CUDA.
Python cuTile JIT compiler allows writing CUDA kernels in straight Python.
AMD and Intel are following up with similar approaches.
If Mojo will still arrive on time to gain wider adoption remains to be seen.
> Python cuTile JIT compiler allows writing CUDA kernels in straight Python.
It is currently not straight Python and will never be.
All these "Performance friendly" python dialects (Tryton, Pythran, CuTile, Numba, Pycell, cuPy, ...) appears like Python but are nothing like Python as soon as you scratch the surface.
They are DSL with a python-looking syntax but made to be optimized, typed and inferred properly. And it feels like it when you use it: in each of them, there is many (most?) python features you simply can not use while you still suffer of inherent python issues.
Lets not lie to ourself: Python is inherently bad for efficiency and performance.
And that goes way beyond the GIL: dynamic typing, reference semantics, monkey patching, ultra-dynamic object model, CPython ABI, BigInt by default, runtime module system, ... are all technical choices that makes sense for a small scripting language but terribly sucks for HPC and efficiency.
The entire Numpy/scipy ecosystem itself is already just a hack around Python limitations for simple CPU bound tensor arithmetics. Mainly because builtin python performance sucks so much that a simple for loop would make Excel looks like a race horse.
Mojo is different.
Mojo tries to start from a clean sheet instead of hacking the existing crap.
And tries to provide a "Python like experience" but on top of a well designed language constructed over past language design experience (Python is >30y old)
And just for that, I wish them success.
> All these "Performance friendly" python dialects (Tryton, Pythran, CuTile, Numba, Pycell, cuPy, ...) appears like Python but are nothing like Python as soon as you scratch the surface.
Which is the whole point. Python has properties that make it bad for massive, fast number twiddling. However, it’s exceptionally nice for doing all the command line parsing and file loading and setup and other wrapping tasks required to run those pipelines.
Fortran’s fantastic at math stuff. I’d sure hate to have to write all the related non-math stuff in it.
And yes, Python’s slower than other languages. But in production, most Python code spends a huge chunk of its time waiting for other code to execute. It takes more CPU for Python to parse an HTTP request or load data files than an AOT language would take, but it’s as efficient sitting there twiddling its thumbs waiting for a DB query or numeric library to finish.
> Mojo tries to start from a clean sheet instead of hacking the existing crap.
Their whole original pitch was to be a superset of Python btw.
I love when dialects for C and C++ count as being proper C and C++, are even argued as being more relevant than ISO standards by themselves, but anyone else that does the same, it is no longer the same language.
As for Python not being the ideal, there we agree, but the solutions with proper performance already exist, Lisp, Scheme, Julia, Futhark,...
Heck maybe someone could dig out StarLisp.
> I love when dialects for C and C++ count as being proper C and C++, are even argued as being more relevant than ISO standards by themselves
I did not argue about CUDA being proper C++ :)
I honestly believe that the best days of C++ as an accelerator language are behind.
That is the main problem currently: We do miss a modern language for system programming that play well with accelerators. C++ is not (really) one of them (Hello aliasing).
I do not know if Mojo will succeed there, but I wish them good luck.
When I first heard about Mojo I somehow got the impression that they intended to make it compatible with existing Python code. But it seems like they are very far away from that for the foreseeable future. I guess you can call back and forth between Python and Mojo but Mojo itself can't run existing Python code.
In their original pitch that was definitely part of it: take Python code, add type hints, get a big speedup. As they've built it out it seems to have diverged.
They also advertised a 36,000x speedup over equivalent Python if I remember correctly, without at any point clarifying that this could only be true in extreme edge cases. Feels more like a pump-dump cryptography scheme than an honest attempt to improve the Python ecosystem.
Well... the article made self deprecating fun of the click bait title, showed the code every step of the way, and actually did achieve the claim (albeit with wall clock time, not CPU/GPU time).
And it wasn't "equivalent python", whatever that means, they did loop unrolling and SIMD and stuff. That can't be done in pure python at all, so there literally is no equivalent python.
If you paid very close attention it was actually clear from the start that the idea was to build a next gen systems language, taking the lessons from Swift and Rust, targeting CPU/GPU/Heterogeneous targets, and building around MLIR. But then also building it with an eye towards eventually embedding/extending Python relatively easily. The Python framing almost certainly helped raise money.
Chris Lattner talked more about the relationship between MLIR and Mojo than Python and Mojo.
So basically Chapel, which is actually being used in HPC.
I don't know Chapel in detail, I was more thinking Hylo. I don't think Chapel has a clear value/reference semantics or ownership/lifetime story? Am I wrong here?
The Mojo docs include two sections dedicated to these topics:
https://mojolang.org/docs/manual/values/
https://mojolang.org/docs/manual/lifecycle/
The metaprogramming story seems to take inspiration from Zig, but the way comptime, parameters and ownership blend in Mojo seems relatively novel to me (as a spectator/layman):
https://mojolang.org/docs/manual/metaprogramming/
I was sort of paying attention to all these ideas and concepts two-three years ago from the sidelines (partially with the idea to learn how Julia could potentially evolve) but it's far from my area of expertise, I might well be getting stuff wrong.
You make use of 'owned', 'shared', 'unmanaged', 'borrowed'.
https://chapel-lang.org/docs/language/spec/classes.html#clas...
I see, seems like the design is not complete and a work in progress (which is the same for Mojos Origins concept I think):
"The details of lifetime checking are not yet finalized or specified. Additional syntax to specify the lifetimes of function returns will probably be needed."
I think Rust proved that lifetimes, ownership and borrow checking can be useful for a mainstream language. The discussions in the Mojo context revolve on how to improve the ergonomics of these versus Rust.
Contrary to Mojo, plenty of people are using it in HPC, and is open source.
https://hpsf.io/blog/2026/hpsf-project-communities-to-gather...
https://developer.hpe.com/platform/chapel/home
See "Projects Powered by Chapel".
So? What point are you making? A different language with different design philosophy, has success in a different niche than Mojo is targeting?
One is used in production already by key laboratories in HPC research, the other wants to be and is far away from being 1.0.
Chapel current version is 2.8.0.