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.

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.

> We have committed to open-sourcing Mojo in Fall 2026.

https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced

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.

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.

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.

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.

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.

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.

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.

Still phase one, doesn't do native Windows.

Meanwhile 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 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 know Mojo is aimed at ML, but I'm actually really interested in trying it for game development :)

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?

I've been keeping my eye on mojo. Honestly though the thing I least like about Python is it's syntax.

Someone else here is bringing up Julia. Which I think is a fine language but the compiler error messages and the library documentation are not what I would want in a language as far along as it is. I'm also worried about the correctness issues I've read about in a blog awhile back. Also I don't feel like I can make the kind of Python module I want with it (because of binary size and time to first x)

That being said I'm only hoping that Mojo can become an option. But I really like to use a REPL and I like the dynamicness of Python. So I might not ever get around to doing anything outside of maybe Numpy for performance.

Python is basically the master glue language at this point.

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.

Modular is going to open source the entire mojo SDK later this year, including the compiler.

> Mojo 1.0 will be finalized later this year, along with opening the compiler and providing language stability.

https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...

>As a compiled, statically-typed language, it's also ideal for agentic programming.

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.

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.

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.

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?

The changelog looks reasonable, seems like the language is moving in the right direction. I'm excited to try it out once it's open sourced. The dependency on glibc is an unfortunate limitation as it means you can't install Mojo on musl-based systems.

[1] https://mojolang.org/releases/v1.0.0b1/

Doesn't anyone here have _one_ kind word to say about its features? Every one seems to be starting with "on the other hand".

Congrats to Chris Lattner and crew! Seems like a neat project. I listened to him talk about Mojo on some podcast a while back and was really impressed. Swift was a runaway success, and I hope he can pull it off again with Mojo! :)

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++?

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.

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.

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.

That's because Mojo told you that. https://web.archive.org/web/20231221132631/https://docs.modu...

> 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.

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.

They just lie a lot, they make fake blogs with fake benchmarks and then they delete them

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.

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.

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.

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.

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)

And just for that, I wish them success.

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.

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...

Might want to take a look at WasmTarget.jl it’s rather new and experimental but could be what you’re looking for!