You know, Herman, I was looking at some old legacy code the other day, and it struck me how much we just accept the Python tax as an unchangeable fact of life. We love the syntax, we love the ecosystem, and we love how quickly we can go from an idea to a working prototype. But then, we just kind of shrug and look the other way when it comes to the massive performance bottlenecks in AI. We have just accepted that if you want it to be fast, you have to hand it off to a different language. But today's prompt from Daniel is about Mojo, a language that is trying to end that compromise for good.
It really is the white whale of programming languages, Corn. People have been trying to build a faster Python since, well, basically since Python started getting slow, which was almost immediately. But Mojo feels different. It is not just another hobbyist project or a niche compiler. It is different because of who is behind it and how it actually approaches the hardware. We are talking about Chris Lattner and his team at Modular. And as we sit here in March of twenty-twenty-six, we are at a massive inflection point. Mojo one point zero is scheduled for release in the first half of this year, and the hype is finally meeting the reality of production environments.
The Lattner Factor is a huge part of the story here. For anyone who has not been tracking the plumbing of modern computing, Chris Lattner is the guy who basically built the foundation of how code turns into action in the modern era. He created LLVM as his PhD dissertation project at the University of Illinois back in two thousand five. Today, LLVM is the backbone of everything from Apple chips to Google infrastructure. If you are using a computer right now, you are using code that Lattner’s architecture touched.
And he did not stop there. He went to Apple and created Swift, which became a top twenty language almost overnight. He led the compiler teams there for over a decade. Then he went to Google and co-created MLIR, which stands for Multi-Level Intermediate Representation. That is a mouthful, but it is actually the secret sauce that makes Mojo possible. He is the person you hire if you want to rewrite how computers think from the ground up. He is not just a language designer; he is an infrastructure architect.
It is an incredibly impressive resume, though I have always found that five-month stint at Tesla Autopilot back in twenty-seventeen to be a bit of a curious footnote. He went in as Vice President of Autopilot Software and was gone before the seat was even warm.
That was a strange blip in an otherwise stellar career. The rumor mill at the time suggested a bit of a culture clash with Elon Musk regarding how to structure the software stack. Lattner is a guy who builds for the long term, and he does not stay in one place if he cannot build the architectural foundations he believes in. After Tesla, he went to Google to fix TensorFlow's infrastructure, then to SiFive to work on RISC-V chips, and finally co-founded Modular in twenty-twenty-two with Tim Davis.
Which brings us to the actual problem Mojo is solving. We are currently living in this weird, fractured two-language world for AI. We explored this a bit in episode ten twenty-one, where we talked about Python being the accidental king of AI. You write your high-level logic in Python because it is easy and expressive, but then all the heavy lifting—the actual math that happens on the GPU—has to be written in C-plus-plus or CUDA.
And that creates a massive friction point, Corn. You have researchers who know Python but cannot optimize the kernels, and you have systems engineers who know CUDA but do not necessarily understand the high-level model architecture. It is a translation layer that costs time, money, and massive amounts of energy. Mojo is essentially saying: what if Python could just talk directly to the metal? What if you did not need two languages? They launched the hype train back in twenty-twenty-three, and the progress since the January release of the Modular Platform twenty-six point one has been significant.
That twenty-six point one release felt like the moment Mojo grew up. They finally graduated the MAX Python API out of its experimental phase. That gave us a PyTorch-like eager mode where you can just call model dot compile for production. It is starting to feel like a real tool rather than a research project. But let us talk about the big elephant in the room, Herman. The marketing. When Mojo first landed, they were throwing around this thirty-five thousand times speedup over Python. That number is legendary at this point, but it also smells a bit like a laboratory benchmark that does not reflect the real world for most people.
It is technically accurate but contextually aggressive. If you write a standard Python loop to calculate the Mandelbrot set, Python is incredibly slow because it is an interpreted language. It is checking types, managing memory, and handling the Global Interpreter Lock for every single iteration of that loop. If you write that same loop in Mojo using a strictly typed function, specialized SIMD vectorization, and multi-threading, you are comparing a bicycle to a supersonic jet. So yes, you can get thirty-five thousand times speedups on specific compute kernels.
So thirty-five thousand times is what happens when you compare the absolute worst way to do something in Python with the absolute best, most optimized way to do it in Mojo.
Well, we try not to say that word here, but you are right. In the real world, for general application code, you are looking at more like two to ten times speedups. Which, to be clear, is still massive. If you can cut your cloud inference bill by sixty percent, which some startups are reporting as of early twenty-twenty-six, you are a hero to your Chief Financial Officer. But we have to be honest about the trade-offs. I have seen reports from machine learning engineers saying that while the code is faster, the debugging time has actually tripled because the tooling is still maturing. You are trading developer time for compute efficiency.
That brings us to the technical how. How does Mojo actually achieve these numbers while staying compatible with Python? You mentioned MLIR earlier. How does that bridge the gap between Python syntax and hardware-level optimization?
This is the core of the innovation. Most compilers take your code and turn it into one single intermediate representation before turning it into machine code. MLIR, which Lattner co-created at Google, allows for multiple levels of representation. It can look at your code at a high level to understand the AI graphs, and then lower it down through different levels of abstraction until it is talking directly to the specific tensor cores of an H-one-hundred or a Blackwell chip. It is a compiler that understands AI hardware as a first-class citizen.
And that is where the distinction between the def and fn keywords comes in, right? This is where the Python superset thing gets interesting.
Precisely. In Mojo, if you use the def keyword, you are basically writing Python. It is dynamic, it is flexible, and it is relatively slow because it maintains that Python compatibility. But if you switch to the fn keyword, you are entering a strictly typed, compiled world. Mojo introduces a borrow checker and an ownership model that feels very much like Rust, but with a syntax that does not make your eyes bleed. It uses let for immutable values and var for mutable ones.
It is like they took the safety and speed of Rust, which we discussed in episode twelve twenty-two, and wrapped it in the approachable skin of Python. But unlike Rust, Mojo is designed from day one for a world where the GPU is the primary processor. Most compilers were designed for General Purpose CPUs. Mojo is built for the era of massive parallelism.
And that leads us to the most ambitious part of the Mojo story: the CUDA replacement strategy. We talked about the dominance of NVIDIA's software layer in episode twelve twenty-four, and Mojo feels like the first real shot across the bow of the CUDA moat. NVIDIA has spent twenty years building a software ecosystem that makes it nearly impossible to leave their hardware. But if Mojo can provide a high-level language that compiles to NVIDIA, and AMD, and Apple Silicon, and even those new Grace superchips, then the hardware becomes a commodity again.
That is a massive geopolitical and commercial shift. If you are a cloud provider or a national government, you hate being locked into one vendor's proprietary language. Mojo offers a potential way out of that trap. Lattner has been very vocal about this. In his May twenty-twenty-five interview with Software Engineering Daily, he explicitly talked about building a CUDA replacement. He is not being shy about the ambition here.
The November twenty-five point seven update was a big step in that direction. They expanded support for NVIDIA Grace and significantly improved the GPU programming model. They are making it so that a developer can write a high-performance kernel without having to learn the dark arts of CUDA C-plus-plus. And the community is responding. As of mid-twenty-twenty-five, the modular slash modular repository on GitHub had over four hundred and fifty thousand lines of code and over six thousand contributors.
But it has not been all sunshine and rainbows. There was what some people call the cold period of twenty-twenty-four. The initial hype in twenty-twenty-three was so high that when people realized the compiler was still closed-source and the standard library was missing basic features, the enthusiasm dipped. There were real concerns about vendor lock-in. You do not want to build your entire company on a language owned by a single startup that might get acquired or disappear.
That was a very real risk, and the Modular team felt the chill. But they responded by committing to open-source the full compiler stack in twenty-twenty-six. That commitment, combined with the twenty-twenty-five updates, really turned the tide. They realized that to be a foundational language, you have to belong to the community, not just a corporate entity. The fact that we are seeing MojoFrame, their dataframe library, beating competitors by nearly three times on standard workloads is proof that the engineering is catching up to the vision.
I do wonder about the timing, though. The AI world moves so fast. By the time Mojo hits one point zero later this year, will the world have moved on to something else? Or is the bottleneck so fundamental that the solution will always be relevant?
I think it is the latter. The bottleneck is physics and economics. We have all this incredible AI hardware coming online, but we are still trying to program it with tools that were designed for a different era. Python is thirty-five years old. It was never meant to orchestrate thousands of parallel GPU cores. It is the glue that is starting to melt under the heat of these massive models. Mojo is the high-temperature epoxy.
What really impressed me in the twenty-six point one release was the compile-time reflection. It allows the code to reason about itself while it is being compiled. You can write generic code that optimizes itself for whatever hardware it happens to find at runtime. That sounds like a dream for portability. But let us be real, Herman. If I am an architect at a mid-sized AI startup right now, is it actually worth the risk to switch? Or am I just adding a massive amount of technical debt by using a language that is still technically in version zero point nine?
It depends on where your pain is. If you are struggling with latency or your cloud bills are killing your margins, you should be experimenting with Mojo for your most expensive kernels right now. The beauty of the Trojan horse strategy is that you do not have to rewrite your whole app. You can just import your existing Python modules and slowly replace the slow bits with Mojo functions. The MAX Python API graduating from experimental status means you can stay in a comfortable, eager-mode development environment while still getting the performance of a compiled graph when you need it.
I still think the thirty-five thousand times benchmark did some damage to their credibility with the more cynical parts of the developer community. You still see people on forums bringing it up as proof that the project is all hype. It is a classic marketing mistake of leading with the best-case scenario.
It is, but once you get past the headline, the engineering is undeniably solid. They are tackling things like linear types and typed errors—sophisticated language features that even some mature languages struggle with. And they are doing it while maintaining that Python-like feel. It is a very pragmatic approach to language design. They are not trying to be the most academically perfect language; they are trying to be the most useful language for the world we actually live in.
Let us talk about the competition for a second. What about things like Triton from OpenAI? That is also trying to make GPU programming easier.
Triton is great, but it is much more specialized. It is focused on writing high-performance kernels for deep learning. Mojo is trying to be a general-purpose language. You could theoretically write a web server or a database in Mojo, not just an AI kernel. That breadth is what gives it the potential to become a foundational language for the next twenty years. It is also why the Julia community has been watching Mojo so closely. Julia has been trying to solve the two-language problem for a long time, but they never quite achieved the mass-market adoption Mojo is aiming for because they were not Python-compatible.
Mojo's genius is realizing that you cannot win if you fight the Python ecosystem. You have to embrace it, absorb it, and then offer a path forward. It is a very Modular way of doing things. They are not just building a language; they are building a platform. The MAX engine is designed to be the runtime for all these models, and Mojo is just the interface.
And we should not forget the financial backing. Modular has raised hundreds of millions of dollars. They are a well-funded machine trying to rewrite the infrastructure of the AI era. It is a bet on the idea that the next decade of computing will be defined by hardware diversity. We are moving away from the world where everything runs on an Intel chip and into a world of specialized AI accelerators. We need a language that can span all of them.
So, if you are a developer listening to this, what is the takeaway? Should you be spending your weekend learning Mojo?
If you are working in AI infrastructure, absolutely. You need to understand the ownership model and the way MLIR works, because even if Mojo is not the final winner, the concepts it is introducing are going to become the industry standard. The era of the lazy, unoptimized Python wrapper is coming to an end. It is about future-proofing your skill set. Even if you do not use Mojo in production today, understanding why it exists tells you everything you need to know about where the bottlenecks are in the industry.
It is the difference between being a driver and being a mechanic. We have had a lot of drivers in the AI space for the last five years, but as the models get bigger and the costs get higher, we are going to need a lot more mechanics. Mojo is the best toolkit those mechanics have ever been offered.
I am genuinely excited to see where it goes after the one point zero release later this year. The roadmap they have laid out is ambitious, but they have hit almost every milestone so far. The fact that they have already saved cloud startups up to sixty percent on inference costs is a huge proof of concept. At the end of the day, the market cares about the bottom line. If Mojo makes AI cheaper and faster to deploy, it will win.
It is hard to bet against Chris Lattner. Every time people have doubted his infrastructure projects in the past—whether it was LLVM or Swift—they have ended up being wrong. He has a way of seeing five years into the future of computing and building the tools we do not even know we need yet. The twenty-six point one release was a clear signal that they are moving from the research phase into the production phase.
It is a high-stakes game. If they succeed, they could be the foundation of the AI era. If they fail, they will be a very interesting footnote in the history of compiler design. But given the momentum and the upcoming open-source milestone, I am leaning toward the former.
We will have to check back in after the one point zero release to see if it lives up to the final promise. In the meantime, I am going to go see if I can make my old Python scripts run even five percent faster without breaking everything.
Good luck with that, Corn. You might find it is easier to just rewrite them in Mojo.
We will see. Thanks as always to our producer, Hilbert Flumingtop, for keeping the gears turning behind the scenes.
And a big thanks to Modal for providing the GPU credits that power this show. They make the heavy lifting look easy.
This has been My Weird Prompts. If you are enjoying the show, find us at myweirdprompts dot com for the full archive and all the ways to subscribe.
We will be back next time with another deep dive. Until then, stay curious.
Catch you later.
