I remember reading about this 4 years ago as the new Chris Lattner project and was super excited, though a little skeptical.
I think that nowadays with vibe/agentic coding, high performance Python-like languages become ever more important. Directly using AI agents to code, say, C++, is painful as the verbose nature of the language often causes the context window to explode.
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.
> Our long-term goal is to make Mojo a superset of Python (that is, to make Mojo compatible with existing Python programs). Python programmers should be able to use Mojo immediately, and be able to access the huge ecosystem of Python packages that are available today.
Right now majority of beginners start programming with a high-level language, say Python or JavaScript - then for more advanced system-level tasks pickup C/C++/Rust/Zig etc.
If Mojo succeeds, it could be the one language spanning across those levels, while simplifying heterogeneous hardware programming.
WOW. Thanks for the comment I don't need to waste my time. So many choices for programming languages why would I go with something that isn't fully open source?
It's a language that wanted to make money from the start.
For example you need to use some Mojo Max library to have fast optimized LLM kernels, but at that point you can just stay with Python that has fast optimized LLM kernels, like flashinfer.
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.
I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax.
Surely this is the sort of thing compiler / language design nerds dream about?
It doesn’t have to guarantee efficiency or provide cutting edge performance in any context … it should just exist!
My understanding is that we can make such a language … but it’s not caught the fancy of someone who could do it
>I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax.
It's already (partly) existed called D language, by default it's garbage collected (GC), can also be program without it or hybrid. It's a modern, backward compatible with C and it's included in GCC.
The linear algebra system in D or Mir GLAS is standalone BLAS implementation written directly in D [1]. It's already proven faster than the other widely existing conventional BLAS like OpenBLAS back in 2016, about ten years ago!
This popular OpenBLAS include Fortran based LAPACK (yes you read it right Fortran) and it is being used by almost all data processing languages currently Matlab, Julia, Rust and also Mojo [2].
Interestingly there is a very early stage of standalone BLAS implementation written directly in Mojo namely mojoBLAS similar to Mir GLAS just started very recently [3].
>Surely this is the sort of thing compiler / language design nerds dream about?
You can say this again.
Especially on the GC side of the programming language since this SIMD / multi thread / multiprocessing / GPU can be abstracted away.
Actually someone recently proposed VGC or virtualized garbage collector for Python in C++ for heteregenous GC [4],[5]. However, the current evaluation excludes JIT compilation, AOT optimization, SIMD acceleration, and GPU offloading.
Kiwi runs computations on small dense arrays in its own runtime, when they are larger it will lower to MLX CPU and eventually to MLX GPU when it is worth it.
As user you don't have to change any code, you just write k.
I'm sure there are other languages designed to take advantage of modern GPUs.
But even with SIMD you can get quite far with array oriented code and many array language implementations will make use of it (BQN, ngn/growler/k, goal, ktye k has a version with SIMD support, …)
julia StaticCompiler.jl is the closest to doing this but its buggy, the error messages are terrible, theres no documentation and its ambiguous whether its still in development. but ive looked, nothing better exists.
Am I old or remembering this wrong... didn't Zuck write the first iteration of Facebook in PHP, and then spend millions to hire people to write something that converted the code to C++?
I am actually on a lookout for a low level language which compiles to web assembly to write a (relatively small) supervised learning model which I plan to be good enough for 5 year old phone CPUs. I have a working prototype in Julia and was planning on (eventually) rewrite it in Rust mostly for the web assembly target. I come from a high level language background so the thought of rewriting in rust is a little daunting. So I was excited to learn about Mojo and find out if they had a WebAssembly target in their compiler.
But then I read this:
> AI native
> Mojo is built from the ground up to deliver the best performance on the diverse hardware that powers modern AI systems. As a compiled, statically-typed language, it's also ideal for agentic programming.
Well, no thank you. I know the irony here but I want nothing to do with a language made for robots.
Sadly for them, Nvidia didn't stay still in the meantime and created the next generation of CUDA, CuTile for Python and soon for C++, through CUDA Tile IR (using a similar compiler stack based on MLIR).
Event though it's not portable, it will likely have far greater usage than Mojo just by being heavely promoted by Nvidia, integrated in dev tools and working alongside existing CUDA code.
Tile IR was more likely a response to the threat of Triton rather than Mojo, at least from the pov of how easy is to write a decently performing LLM kernel.
My understanding from speaking with a few Tile IR devs on dates is that its primary motivation was providing better portability for programming tensor cores than PTX offers. Nobody ever told me they saw it as a response to anything other than customer feedback.
I do wonder if Mojo was a great idea just a little too late to the party. Porting ‘prototypes’ from Python to lower level languages is fairly trivial now with LLMs.
Modern LLMs are perfectly capable to learn the syntax of a new language on the fly and write great Code. E.g. there is an official Mojo syntax skill you can use and works well
Advertising prominently with "AI native" seems necessary today, at least for some folks. To me, that's kind of off-putting, since it doesn't really say anything.
Can anyone of the AI enthusiasts here explain, why, or, what is meant by
> As a compiled, statically-typed language, it's also ideal for agentic programming.
Python+ruff+pycheck and TypeScript are compiled to bytecode instead of machine code. They’re not statically typed in the Rust sense. And yet, I’ve watched model crank out good, valid in both of those without needing to be either strictly “compiled” or “statically typed”. Turns out AI couldn’t care less about those properties as long as you have good tooling to quickly check the code and iterate.
Current LLMs have been trained on extensive libraries of past code. Therefore, LLMs will for the foreseeable future work better for established languages than new ones. Especially languages with a lot of open source code available, like Python. That's a big problem for incumbents without any existing code to train LLMs on.
Thus this desparate "AI native" marketing is probably necessary to even be considered relevant in an "agentic" world. Whether it's enough, only time will tell.
I’m relatively new to programming but I wish they had used a functional language syntax rather than an object oriented one as the basis for mojo.
From my experience, AI revolves a lot around building up function pipelines, computing their derivatives, and passing tons of data through them; which composability and higher order functions from functional programming make it a breeze to describe.
I also feel that other fields than AI are moving towards building up large functional pipelines to produce outputs, which would make mojo suitable for those fields as well. I’m building in the space of CAD for example and I’d love to use a “functional mojo” language.
> 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)
Is there any project that showcases Mojo for running neural network models on the GPU - like ideally something like llama.cpp that could run one or more existing models to showcase the readability and performance?
Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime that is more powerful than Zig, Rich type system, first class SIMD support, etc.
Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig.
Very excited for Mojo once it's open sourced later this year.
Not OP, but see the entire section on metaprogramming: https://mojolang.org/nightly/docs/manual/metaprogramming/. Mojo's compile-time programming is influenced by Zig, but has features that are not in Zig e.g traits, generics (real generics), and constraints, that work together.
Mojo looks neat but I'm pretty satisfied with Julia at this point for high performance numerical computing across CPU, GPU, etc. I can't help but feel this niche is already mostly solved beyond having Python like syntax. Even Python has things like Numba and Triton that are effective for less complicated / more self contained type problems.
54 comments
[ 3.4 ms ] story [ 70.5 ms ] threadMeanwhile 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.
So will Mojo still arrive on time to gain wider adoption?
Time will tell.
I think that nowadays with vibe/agentic coding, high performance Python-like languages become ever more important. Directly using AI agents to code, say, C++, is painful as the verbose nature of the language often causes the context window to explode.
> Our long-term goal is to make Mojo a superset of Python (that is, to make Mojo compatible with existing Python programs). Python programmers should be able to use Mojo immediately, and be able to access the huge ecosystem of Python packages that are available today.
If Mojo succeeds, it could be the one language spanning across those levels, while simplifying heterogeneous hardware programming.
Modular is giving you at least a public promise that they will open source Mojo it this year but some how here it is a problem.
Unbelievable.
For example you need to use some Mojo Max library to have fast optimized LLM kernels, but at that point you can just stay with Python that has fast optimized LLM kernels, like flashinfer.
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.
Surely this is the sort of thing compiler / language design nerds dream about?
It doesn’t have to guarantee efficiency or provide cutting edge performance in any context … it should just exist!
My understanding is that we can make such a language … but it’s not caught the fancy of someone who could do it
It's already (partly) existed called D language, by default it's garbage collected (GC), can also be program without it or hybrid. It's a modern, backward compatible with C and it's included in GCC.
The linear algebra system in D or Mir GLAS is standalone BLAS implementation written directly in D [1]. It's already proven faster than the other widely existing conventional BLAS like OpenBLAS back in 2016, about ten years ago!
This popular OpenBLAS include Fortran based LAPACK (yes you read it right Fortran) and it is being used by almost all data processing languages currently Matlab, Julia, Rust and also Mojo [2].
Interestingly there is a very early stage of standalone BLAS implementation written directly in Mojo namely mojoBLAS similar to Mir GLAS just started very recently [3].
>Surely this is the sort of thing compiler / language design nerds dream about?
You can say this again.
Especially on the GC side of the programming language since this SIMD / multi thread / multiprocessing / GPU can be abstracted away.
Actually someone recently proposed VGC or virtualized garbage collector for Python in C++ for heteregenous GC [4],[5]. However, the current evaluation excludes JIT compilation, AOT optimization, SIMD acceleration, and GPU offloading.
[1] OpenBLAS:
https://en.wikipedia.org/wiki/OpenBLAS
[2] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
[3] mojoBLAS:
https://github.com/shivasankarka/mojoBLAS
[4] Virtual Garbage Collector (VGC): A Zone-Based Garbage Collection Architecture for Python's Parallel Runtime:
https://arxiv.org/abs/2512.23768
[5] VGC-for-arxiv:
https://github.com/Abdullahlab-n/VGC-for-arxiv
Currently supports CPU and GPU on macOS and CPU on linux.
https://kiwilang.com
https://github.com/kiwi-array-lang/kiwi
Kiwi runs computations on small dense arrays in its own runtime, when they are larger it will lower to MLX CPU and eventually to MLX GPU when it is worth it.
As user you don't have to change any code, you just write k.
I'm sure there are other languages designed to take advantage of modern GPUs.
But even with SIMD you can get quite far with array oriented code and many array language implementations will make use of it (BQN, ngn/growler/k, goal, ktye k has a version with SIMD support, …)
That's a very big claim.
But then I read this:
> AI native
> Mojo is built from the ground up to deliver the best performance on the diverse hardware that powers modern AI systems. As a compiled, statically-typed language, it's also ideal for agentic programming.
Well, no thank you. I know the irony here but I want nothing to do with a language made for robots.
Event though it's not portable, it will likely have far greater usage than Mojo just by being heavely promoted by Nvidia, integrated in dev tools and working alongside existing CUDA code.
Tile IR was more likely a response to the threat of Triton rather than Mojo, at least from the pov of how easy is to write a decently performing LLM kernel.
Can anyone of the AI enthusiasts here explain, why, or, what is meant by
> As a compiled, statically-typed language, it's also ideal for agentic programming.
Python+ruff+pycheck and TypeScript are compiled to bytecode instead of machine code. They’re not statically typed in the Rust sense. And yet, I’ve watched model crank out good, valid in both of those without needing to be either strictly “compiled” or “statically typed”. Turns out AI couldn’t care less about those properties as long as you have good tooling to quickly check the code and iterate.
Thus this desparate "AI native" marketing is probably necessary to even be considered relevant in an "agentic" world. Whether it's enough, only time will tell.
From my experience, AI revolves a lot around building up function pipelines, computing their derivatives, and passing tons of data through them; which composability and higher order functions from functional programming make it a breeze to describe.
I also feel that other fields than AI are moving towards building up large functional pipelines to produce outputs, which would make mojo suitable for those fields as well. I’m building in the space of CAD for example and I’d love to use a “functional mojo” language.
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
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.
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.
Since there is not much Mojo code in the wild so the LLMs were trained on it, I wonder how it will work in practice.
Probably the agents will make lots of mistakes and you will spend 10x the tokens compared to using a language the model are well versed in.
If more than a few percent of execution time is spent in Python you are probably doing it wrong.
Personally I don't even understand why Cython is a thing, just write performance critical functions in other languages:
<https://pypi.org/project/rustimport/>
<https://pypi.org/project/import-zig/>
Note that you can even start threads in those languages and use function calls as pseudo-RPC. All without an overly complex build system.
Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig.
Very excited for Mojo once it's open sourced later this year.
It would be great if you can elaborate more here. I can't make the conclusion from Mojo's docs now.
What’s that supposed to mean?