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.
>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.
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...
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.
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:
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):
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.
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.
Python interop
> Mojo natively interoperates with Python so you can eliminate performance bottlenecks in existing code without rewriting everything. You can start with one function, and scale up as needed to move performance-critical code into Mojo. Your Mojo code imports naturally into Python and packages together for distribution. Likewise, you can import libraries from the Python ecosystem into your Mojo code.
> they intended to make it compatible with existing Python code
That was the original claim, but it was quietly removed from the website. (Did they fall for the common “Python is a simple language” misconception?).
Now they promise I can “write like Python”, but don’t even support fundamentals like classes (which are part of stage 3 of the roadmap, but they’re still working on stage 1).
Maybe Mojo will achieve all its goals, but so far has been over-promising and under-delivering - it’s starting to remind me of the V language.
The communication had me try to run some very simple python code assuming it of course should run (reading files line by line), which didn't work at all.
For me this was a big disappointment, and I wonder how much this has backfired across developers.
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.
And for not staying behind, Intel and AMD are doing similar efforts, and then we have the whole CPython JIT finally happening after so many attempts.
Not to mention efforts like GraalPy and PyPy.
And all these efforts work today in Windows, which is quite relevant in companies where that is the assigned device to most employees, even if the servers run Linux distros.
I keep wondering if this isn't going to be another Swift for Tensorflow kind of outcome.
People keep mistaking Mojo as good syntax for writing GPU code, and so imagine Nvidia's Python frameworks already do that. But... would CuTile work on AMD GPUs and Apple Silicon? Whatever Nvidia does will still have vendor lock-in.
Indeed, but Intel and AMD are also upping their Python JIT game, and in the end Mojo code isn't portable anyway.
You always need to touch the hardware/platform APIs at some level, because even if the same code executes the same, the observed performance, or in the case of GPUs the numeric accuracy has visible side effects.
It is portable in that you can write code to target multiple platforms in the same codebase. Mojo has powerful compile-time metaprogramming that allows you to tell the compiler how to specialise using a compile-time conditional, e.g. https://github.com/modular/modular/blob/9b9fc007378f16148cfa...
Of course, this won't be necessary in most cases if you're building on top of abstractions provided by Modular.
You don't get this choice using vendor-specific libraries; you're locked into this or that.
Yes you do, you get PyTorch or whatever else, built on top of those vendor-specific libraries.
That is the thing with Mojo, when it arrives as 1.0, the LLM progress and the investment that is being done in GPU JITs for Python, make it largely irrelevant for large scale adoption.
Sure some customers might stay around, and keep Modular going, the gold question is how many.
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.
It's been really interesting to see all the desperation on hero pages for all these products and services ever since AI came into prominence. I think the funniest for me was opening IBM DB2 product page and seeing it labeled as 'AI database'. Hysterical.
> why, or, what is meant by
More errors caught at compile time means an agent can quickly check their work statically without unit and other tests.
I don't know what they meant by it, and I share your opinion that "AI native" is somewhat meaningless for a programming language like this.
Regarding compilation and static typing, it's extremely helpful to be able to detect issues at compile time when doing agentic programming. That way, you don't run into as many problems at runtime, which of course the agent has more difficulty addressing. Unit tests can help bridge the gap somewhat but not entirely.
What's not stated on their website is that Mojo is likely a bad choice for agentic programming simply because there isn't much Mojo training data yet.
I've recently used Claude to write quite a bit of mojo (https://github.com/boxed/TurboKod) and I can quite confidently say that Claude will write deprecated mojo syntax a lot, but the compiler tells it and it fixes it pretty fast too. The only reason I notice is that I look at Claude while it's working and I see the compilation warnings (and sometimes Claude is lazy and doesn't compile so I have to see it).
But yea, to write mojo 1.0 code even after getting errors might take a new training round, so next or even next-next models.
Because a coding agent (when instructed well) will try to make a piece of code work in a loop. Static typing and compilation help in the process (no more undefined variables discovered at runtime for instance). But that’s not bullet proof at all as most of us know
> 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)
> 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. No, 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 had 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.
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,...
> 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.
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.
The vast majority of real world ML code today is written in languages like Python and C++. Relatively few people outside of academia and online forums are functional language enthusiasts. The industry is also looking like most actual coding is going to be done by LLMs going forward, so it makes little sense to design new languages with a niche potential user base since LLMs need a ton of training data. I’m think that was a factor in deciding to base mojo on Python along with the other reasons they state.
agree with all of this. Though i'd say: since the language is mostly read by humans rather than written, in my opinion, it makes even more sense to have a language syntax that actually matches intent. In the case of Machine Learning, it's mostly connecting functions together and acting on them, which matches functional syntax.
LLMs are also already very effective at writing ML-inspired syntax (like ocaml or f#) as they have plenty of data to train on, making llms effective from day one if a similar syntax was chosen.
I'm in the same boat, this would've been in the family of the first language that neural nets and AI were created with back decades ago, Lisp. Coming from the awesome project of Swift, which to their credit, was a massive undertaking to convince Apple execs, I was still hoping for a functional language approach like Haskell with the practicality of Clojure.
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.
As someone who would have strong reasons to invest time in Modular (simple high performant language for implementing bioinformatics scripts), I would say primarily the worry that development might be too tied to Modular, the startup behind it, which eventually might pivot into other priorities.
One would want to see either a strong community build up around it, or really hard evidence for a long-term commitment to the language from Modular. And the latter will take a long time to be assured of I think.
Also, editing tools need to catch up before very wide adoption of a language with a lot of new syntax.
I have no time for or interest in proprietary compilers. The standard library is Apache 2, but the license link on their home page is to a long terms of service thing. I’d like to be wrong because it looks interesting. Until then, this doesn’t exist in my world.
I bet that’s true for a great many people. There are too many wonderful FOSS languages to bother with one you can’t fix or adapt or share.
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.
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.
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?
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++?
If you're looking for a language that aims to solve the "two-language problem" like Mojo, but want something more open, more mature and less influenced by VC funding, check out Julia: https://julialang.org/
I used Julia a lot when I was studying statistics (which I dropped out of) back in 2015, but I recently (like last weekend) came back to it to write a prototype of a supervised learning model, and I have to say, coming back to it was pure joy. And my model prototype was indeed fast enough for me.
Now I will probably rewrite the model in rust if I want to do anything with it (mostly for the web assembly target as I want this thing to run in browsers) but I will for sure be using Julia for further experimentation. Lovely language.
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.
I’ve written Python for the past 25 years or so. I dig it. But I don’t think I’ve started a new Python project since starting to experiment with Rust. A lot (not all!, but a lot) of Rust patterns look a lot like Python if you squint at it just right. I also think that writing lots of Rust has made me better at writing Python. The things Rust won’t let you get away with are things you shouldn’t be doing almost anywhere else.
Go on, give it a shot. It stops being intimidating soon! And remember that the uv we all love was heavily influenced by Cargo.
Good call. It’s not the first language I think of for most things but there’s no great reason why not to. I probably reach for Rust first because I’m more familiar with it and the projects I want to work on were already written in it.
I can only go get coffee waiting for my Python test suite to finish so many times per day. I write Rust because the strict type system accelerates the iteration speed for producing correct code more than any other language in its class.
I actually have written Rust, but it has been a minute. I think my last project (a backend for a massive online multiplayer theremin jam session [site no longer up; but HN discussion still exists: https://news.ycombinator.com/item?id=10875211] 10 years ago).
I remember Rust very fondly in fact. And I had the same experience as you, learning Rust made me a better Javascript programmer. Lets see if a little neural network can be as fun.
Mojo has been suffering in their communication from targeting VCs rather than users. They never actually had a clear "Mojo extends Python" MVP or even strategy to get to an MVP anytime soon. And the language started developing before AI Agents were a thing and has more to do with building around state of the art LLVM tooling than AI Agents. But I guess "easier lifetime semantics than Rust and native access to MLIR intrinsics" doesn't raise money...
I have tons of experience with python, possibly more actual work experience than any other language, and I do think the indentation is a bit of a problem. Obviously not a huge one, but still something I wished they had done differently. Because I like to have a robust format-on-save wired into my editor, and you just cannot quite have that when indentation is meaningful.
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.
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.
They coulda made it Scala!
>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.
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...
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.
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?
That was what was originaly advertised, they wanted to be what Kotlin is to Java but for Python. They quickly turned tails on this.
That and the not completely open source development model is what has always felt very vaporwary to me.
From the site:
Python interop > Mojo natively interoperates with Python so you can eliminate performance bottlenecks in existing code without rewriting everything. You can start with one function, and scale up as needed to move performance-critical code into Mojo. Your Mojo code imports naturally into Python and packages together for distribution. Likewise, you can import libraries from the Python ecosystem into your Mojo code.
> they intended to make it compatible with existing Python code
That was the original claim, but it was quietly removed from the website. (Did they fall for the common “Python is a simple language” misconception?).
Now they promise I can “write like Python”, but don’t even support fundamentals like classes (which are part of stage 3 of the roadmap, but they’re still working on stage 1).
Maybe Mojo will achieve all its goals, but so far has been over-promising and under-delivering - it’s starting to remind me of the V language.
The communication had me try to run some very simple python code assuming it of course should run (reading files line by line), which didn't work at all.
For me this was a big disappointment, and I wonder how much this has backfired across developers.
isn't that achieved by Codon?
Really the only thing good about Python is its ecosystem.
Nah, it's also a very fine language for getting an idea down quickly.
Might not have the niceties purists like, but perhaps that's exactly it's a great language for that.
It's like executable pseudocode, and unlike other languages, all the ceremony is optional.
People flocked to it way before it became a "must" for ML and CS thanks to that ecosystem becoming dominant.
but that ecosystem is realy good.
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.
And for not staying behind, Intel and AMD are doing similar efforts, and then we have the whole CPython JIT finally happening after so many attempts.
Not to mention efforts like GraalPy and PyPy.
And all these efforts work today in Windows, which is quite relevant in companies where that is the assigned device to most employees, even if the servers run Linux distros.
I keep wondering if this isn't going to be another Swift for Tensorflow kind of outcome.
People keep mistaking Mojo as good syntax for writing GPU code, and so imagine Nvidia's Python frameworks already do that. But... would CuTile work on AMD GPUs and Apple Silicon? Whatever Nvidia does will still have vendor lock-in.
Indeed, but Intel and AMD are also upping their Python JIT game, and in the end Mojo code isn't portable anyway.
You always need to touch the hardware/platform APIs at some level, because even if the same code executes the same, the observed performance, or in the case of GPUs the numeric accuracy has visible side effects.
It is portable in that you can write code to target multiple platforms in the same codebase. Mojo has powerful compile-time metaprogramming that allows you to tell the compiler how to specialise using a compile-time conditional, e.g. https://github.com/modular/modular/blob/9b9fc007378f16148cfa...
Of course, this won't be necessary in most cases if you're building on top of abstractions provided by Modular.
You don't get this choice using vendor-specific libraries; you're locked into this or that.
Yes you do, you get PyTorch or whatever else, built on top of those vendor-specific libraries.
That is the thing with Mojo, when it arrives as 1.0, the LLM progress and the investment that is being done in GPU JITs for Python, make it largely irrelevant for large scale adoption.
Sure some customers might stay around, and keep Modular going, the gold question is how many.
Interesting, how big impact is CuTile?
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.
It’s the new “…on the blockchain”.
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.
It's been really interesting to see all the desperation on hero pages for all these products and services ever since AI came into prominence. I think the funniest for me was opening IBM DB2 product page and seeing it labeled as 'AI database'. Hysterical.
> why, or, what is meant by More errors caught at compile time means an agent can quickly check their work statically without unit and other tests.
I don’t really consider myself an “AI enthusiasts”, but I do use it.
So, agents tend to do better the more feedback they can get. Type checking is pretty good for catching a bunch of dumb mistakes automatically.
The point is more hints for the agent is more better most of the time.
So just like for humans...
I don't know what they meant by it, and I share your opinion that "AI native" is somewhat meaningless for a programming language like this.
Regarding compilation and static typing, it's extremely helpful to be able to detect issues at compile time when doing agentic programming. That way, you don't run into as many problems at runtime, which of course the agent has more difficulty addressing. Unit tests can help bridge the gap somewhat but not entirely.
What's not stated on their website is that Mojo is likely a bad choice for agentic programming simply because there isn't much Mojo training data yet.
I've recently used Claude to write quite a bit of mojo (https://github.com/boxed/TurboKod) and I can quite confidently say that Claude will write deprecated mojo syntax a lot, but the compiler tells it and it fixes it pretty fast too. The only reason I notice is that I look at Claude while it's working and I see the compilation warnings (and sometimes Claude is lazy and doesn't compile so I have to see it).
But yea, to write mojo 1.0 code even after getting errors might take a new training round, so next or even next-next models.
https://mojolang.org/docs/tools/skills/
Because a coding agent (when instructed well) will try to make a piece of code work in a loop. Static typing and compilation help in the process (no more undefined variables discovered at runtime for instance). But that’s not bullet proof at all as most of us know
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. No, 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 had 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.
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.
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.
The vast majority of real world ML code today is written in languages like Python and C++. Relatively few people outside of academia and online forums are functional language enthusiasts. The industry is also looking like most actual coding is going to be done by LLMs going forward, so it makes little sense to design new languages with a niche potential user base since LLMs need a ton of training data. I’m think that was a factor in deciding to base mojo on Python along with the other reasons they state.
agree with all of this. Though i'd say: since the language is mostly read by humans rather than written, in my opinion, it makes even more sense to have a language syntax that actually matches intent. In the case of Machine Learning, it's mostly connecting functions together and acting on them, which matches functional syntax. LLMs are also already very effective at writing ML-inspired syntax (like ocaml or f#) as they have plenty of data to train on, making llms effective from day one if a similar syntax was chosen.
I'm in the same boat, this would've been in the family of the first language that neural nets and AI were created with back decades ago, Lisp. Coming from the awesome project of Swift, which to their credit, was a massive undertaking to convince Apple execs, I was still hoping for a functional language approach like Haskell with the practicality of Clojure.
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.
I was excited when Mojo launched and thought it might grow big quick. I don't see much traction. The pitch is compelling. What could be the issue?
As someone who would have strong reasons to invest time in Modular (simple high performant language for implementing bioinformatics scripts), I would say primarily the worry that development might be too tied to Modular, the startup behind it, which eventually might pivot into other priorities.
One would want to see either a strong community build up around it, or really hard evidence for a long-term commitment to the language from Modular. And the latter will take a long time to be assured of I think.
Also, editing tools need to catch up before very wide adoption of a language with a lot of new syntax.
I have no time for or interest in proprietary compilers. The standard library is Apache 2, but the license link on their home page is to a long terms of service thing. I’d like to be wrong because it looks interesting. Until then, this doesn’t exist in my world.
I bet that’s true for a great many people. There are too many wonderful FOSS languages to bother with one you can’t fix or adapt or share.
Mojo is still NOT open source (the standard library is but not the compiler). Open source is table stakes for a modern programming language.
- Doesn't support Windows, which is what many companies give their employees, outside Silicon Valey like culture
- The MLIR approach, which was also designed by Chris Lattner while at Google, has proven quite valuable to create Python JIT DSL
- The Python ecosystem now being taken seriously by the main GPU vendors, thanks to MLIR, as all their proprietary compilers are based out of LLVM
- Others remember Swift for Tensorflow
When it was announced it was not generally available for everyone to try out. There was a waitlist phase.
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.
Not to mention that C++ basically can't be made to be safe. But Rust is probably fine.
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.
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?
> We have committed to open-sourcing Mojo in Fall 2026.
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
Doesn't anyone here have _one_ kind word to say about its features? Every one seems to be starting with "on the other hand".
Many of us were already around during Swift for Tensorflow.
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++?
https://en.wikipedia.org/wiki/Hack_(programming_language)
Very bold of them expecting people to use a language with a closed source compiler in the 2020s.
If you're looking for a language that aims to solve the "two-language problem" like Mojo, but want something more open, more mature and less influenced by VC funding, check out Julia: https://julialang.org/
I used Julia a lot when I was studying statistics (which I dropped out of) back in 2015, but I recently (like last weekend) came back to it to write a prototype of a supervised learning model, and I have to say, coming back to it was pure joy. And my model prototype was indeed fast enough for me.
Now I will probably rewrite the model in rust if I want to do anything with it (mostly for the web assembly target as I want this thing to run in browsers) but I will for sure be using Julia for further experimentation. Lovely language.
from what I understand the goal for now is not to get the people to use it, but for enthusiasts to try it
What enthusiast worth getting feedback from is going to tinker with a locked up language?
You'd be surprised. Anyway, the compiler will be opened with 1.0 release, that's why reaching beta is exciting.
They've said they'll open source the compiler alongside the 1.0 release.
>No more choosing between productivity and performance - Mojo gives you both.
That's a very big claim.
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.
I’ve written Python for the past 25 years or so. I dig it. But I don’t think I’ve started a new Python project since starting to experiment with Rust. A lot (not all!, but a lot) of Rust patterns look a lot like Python if you squint at it just right. I also think that writing lots of Rust has made me better at writing Python. The things Rust won’t let you get away with are things you shouldn’t be doing almost anywhere else.
Go on, give it a shot. It stops being intimidating soon! And remember that the uv we all love was heavily influenced by Cargo.
If you’re searching for a language that has the same strong memory safety than rust but is a bit easier to write, you should give Swift a go.
Good call. It’s not the first language I think of for most things but there’s no great reason why not to. I probably reach for Rust first because I’m more familiar with it and the projects I want to work on were already written in it.
I can't go get coffee so many times per day, there are better compiled languages to chose from, while offering Python like ergonomics.
I can only go get coffee waiting for my Python test suite to finish so many times per day. I write Rust because the strict type system accelerates the iteration speed for producing correct code more than any other language in its class.
Which is why the solution is to pick neither, rather something with Python like productivity and a mix of JIT/AOT tooling.
Some alternatives are as old as 1958.
I actually have written Rust, but it has been a minute. I think my last project (a backend for a massive online multiplayer theremin jam session [site no longer up; but HN discussion still exists: https://news.ycombinator.com/item?id=10875211] 10 years ago).
I remember Rust very fondly in fact. And I had the same experience as you, learning Rust made me a better Javascript programmer. Lets see if a little neural network can be as fun.
Mojo has been suffering in their communication from targeting VCs rather than users. They never actually had a clear "Mojo extends Python" MVP or even strategy to get to an MVP anytime soon. And the language started developing before AI Agents were a thing and has more to do with building around state of the art LLVM tooling than AI Agents. But I guess "easier lifetime semantics than Rust and native access to MLIR intrinsics" doesn't raise money...
Does it have the indentation thing? That would be a no go for a lot of people
Only incredibly inexperienced people think indentation in python is a problem.
I have tons of experience with python, possibly more actual work experience than any other language, and I do think the indentation is a bit of a problem. Obviously not a huge one, but still something I wished they had done differently. Because I like to have a robust format-on-save wired into my editor, and you just cannot quite have that when indentation is meaningful.
Use black as format on save and you will never have a problem with that. https://github.com/psf/black
Sure, black's pretty good and definitely better than nothing.
Just wanted to provide an easy counterpoint to the logical fallacy by IceDane.
Yes, indeed, indentation is one of the very few things in Python which aren't problematic!