A friend messaged me at 1am with a GitHub link and the words “Python is finished.” I looked at it, said “sure”, and went back to sleep. In the morning I actually read it properly, and the thing he sent was real news, just not the news he thought it was.
Modular open sourced the Mojo compiler. Not the standard library, which has been open since 2024. The compiler and the toolchain, under Apache 2.0 with LLVM exceptions, sitting in the same modular GitHub repo as everything else they ship. That happened a week after Mojo hit 1.0.
I’ve been half-watching Mojo since 2023 with a fairly cynical eye, so let me tell you what I think actually changed here and what didn’t. Short version: the license changed, my Tuesday didn’t.
What Modular actually shipped
The announcement post is short and unusually free of marketing. The claim is simple: the compiler, the tooling, and everything you need to build the language yourself are in the modular/modular repository under Apache 2.0 with the LLVM exceptions.
That license choice matters more than the announcement suggests. Apache 2.0 plus LLVM exceptions is what Swift and LLVM itself use, and it’s the reason you can compile a binary with the toolchain and ship it without dragging attribution requirements into your distribution. If Modular had picked something source-available and custom, the entire release would have been theatre. They didn’t.
Building it is one command, which I’ll admit surprised me:
git clone https://github.com/modular/modular.git
cd modular
./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo
Bazel downloads or builds the whole world for you. There’s also --config=prebuilt-mojo if you just want the nightly binary and don’t care about compiler internals, which describes roughly everyone reading this.
There’s a second thing in that 1.0 announcement that got less attention than the license: source stability. Up to now, Mojo had the reputation of a language where you pinned a nightly and prayed, because syntax you learned in spring might not compile in autumn. I know two people who abandoned side projects over exactly that. A 1.0 with a stability commitment is what makes the open source release meaningful, because reading a compiler you can’t rely on the syntax of is an academic exercise. The two announcements landing a week apart is not a coincidence, and it’s the right order.
The part that got buried
Open source usually implies you can send a patch. Here, you can’t. From the announcement: they aren’t ready to take contributions to the compiler and tooling, and they’re aiming to accept them by the end of the year. Their stated reason is that they want to be deliberate about contribution handling “in today’s era of AI coding”, which I read as: we do not want a thousand agent-authored pull requests against a compiler.
I don’t hate that reasoning. I’ve reviewed enough drive-by PRs to know what a floodgate costs. But “you can read it, you can fork it, you can’t upstream to it yet” is a different product than what most people picture when they hear a compiler went open source.
The other thing worth saying out loud, because the announcement doesn’t: Qualcomm completed its acquisition of Modular in July. So the compiler that was just open sourced belongs to a chip company now. Apache 2.0 means a fork is legally possible if the direction ever goes somewhere the community hates. Whether anyone has the appetite to maintain a fork of a language this young is a separate question, and the honest answer is probably no.
What the code looks like when you’re coming from Python
Mojo started life pitched as a superset of Python. That plan officially changed in 2025. It’s now its own language with Python-flavoured syntax, aimed at GPU and accelerator work.
Here’s the shape of it. Ordinary Python:
# Fine. Also, at a few million elements, slow.
def sum_squares(xs):
total = 0.0
for x in xs:
total += x * x
return total
The Mojo version reads almost the same, except the types aren’t optional and the compiler knows them before anything runs:
fn sum_squares(xs: List[Float64]) -> Float64:
var total: Float64 = 0.0
for i in range(len(xs)):
total += xs[i] * xs[i]
return total
fn instead of def gets you strict typing and no implicit dynamism. That’s the trade. You write more annotations, you get a compiler that can actually vectorise the loop instead of chasing pointers through a PyObject for every element.
It’s worth being clear about the history here, because a lot of the commentary is still running on 2023 information. The original pitch was that Mojo would be a strict superset of Python, so you could rename a file and start optimising incrementally. That was the thing that made people pay attention, and it’s the thing that’s no longer true. Modular said in 2025 that Mojo may or may not become a full superset, and that this was fine. Reading the current docs, the direction is unmistakable: it’s a systems language that borrowed Python’s syntax because Python’s syntax is familiar to the people who write GPU kernels, not because it wants to run your Django app.
That reframing is honest, and it also quietly removes the killer feature. “Gradually speed up your existing Python” is a migration path. “Learn a new language with an ownership model” is a rewrite. Those are very different asks, and the second one competes directly with Rust, C++, and Julia rather than sliding in underneath them.
I’m not going to pretend I’ve shipped anything in Mojo. I haven’t. I’ve written maybe two hundred lines of it, all of it toy code, and I found the ownership model harder to hold in my head than Rust’s, partly because the docs assume you already know why you’d want it. If you want the real reference it lives at mojolang.org.
Who this is for, and it’s probably not you
If you build web applications, this release changes nothing about your week. Mojo isn’t competing for the job that Laravel or Next.js does. It’s competing for the job CUDA C++ does, and the pitch is that you can write kernels without leaving something that looks like Python.
That’s a genuinely good pitch for a narrow group: people writing inference kernels, people doing numerical work who currently drop into C++ when NumPy runs out, people who own the performance floor of an AI product. If your bottleneck is a database query or a network round trip, a faster kernel language buys you nothing at all.
I say that with some feeling, because I’ve watched a team spend six weeks rewriting a service in a faster language to fix a latency problem that turned out to be a missing index and a chatty external API. The rewrite made the compute portion about four times faster. The compute portion was eleven percent of the response time. Everyone learned something, nobody wanted to talk about it, and the index took twenty minutes.
The useful question isn’t whether Mojo is fast. It obviously is; that’s the entire design goal and there’s no interesting debate to have. The question is whether the part of your system that’s slow is the part a language can fix. For most application work, it isn’t, and no amount of GitHub stars changes that.
This is the same filter I apply when people ask whether they should learn Rust or Go, and I wrote up the heuristic I actually use for that. It applies here too. Pick a language because you have a problem shaped like it, not because a compiler got a new license.
Why open sourcing a compiler is still a real thing
Cynicism aside, there’s a practical reason to care even if you never write a line of it.
A closed compiler is a single point of failure with a business model attached. Every team I know that evaluated Mojo over the last three years ran into the same objection in the same meeting: what happens to our code if Modular gets acquired or pivots? Modular then got acquired. The compiler being Apache 2.0 is the only answer to that question that survives contact with a procurement review.
That’s the change. Not performance, not syntax, not adoption. Risk. A language you can’t fork is a bet on a company. A language you can fork is a bet on a language.
I want to be careful not to oversell that, though, because “you can fork it” is doing a lot of load-bearing work in arguments like this and it’s rarely tested. Forking a compiler is not forking a library. You need people who understand MLIR, you need CI that can build across the accelerator targets the language exists to serve, and you need to keep doing that for years while the upstream you forked from moves. Realistically, an Apache 2.0 compiler protects you against the worst outcome, which is a licence change that makes your existing code undistributable. It does not promise you a healthy community project if Qualcomm loses interest. Those are different guarantees and people conflate them constantly.
The honest version of the risk argument is narrower and still worth something: if you write Mojo today, the code you’ve written stays legally yours to compile and ship, whatever happens to the company. Three years ago that wasn’t true. For anything you’d put in production, that’s the difference between a conversation and a non-starter.
Simon Willison made a similar point when the news landed, and he’d been tracking the promise since the original 2023 pledge. Three years is a long time to keep a promise in this industry. They kept it.
What I’d actually do this week
Nothing dramatic. Two things, if you’re curious:
Clone the repo and run the hello world with --config=prebuilt-mojo. Fifteen minutes, and you’ll know within one file whether the syntax annoys you. That reaction is worth more than any benchmark someone posts.
Then, if you have an actual numeric hot path, write it twice: once in whatever you use now, once in Mojo, and time both on your own data. Not a synthetic benchmark from a blog post. Yours. I do this kind of measurement for clients often enough that it’s part of how I scope performance work, and the result is boring more often than not. Boring is a fine outcome. It means you keep the code you already have.
And if you don’t have a hot path? Then congratulations, this release is a piece of interesting news you can skip, and I’ll be doing exactly the same.
