Modular releases Mojo compiler and toolchain under Apache 2.0 after Mojo 1.0
- Modular released the full Mojo compiler, tooling, and language source in its public
modularGitHub repository under Apache 2.0 with LLVM exceptions. - The release follows Mojo 1.0 and four years in which Modular developed the language publicly while keeping its compiler closed; the standard library and hundreds of thousands of lines of Mojo kernel code had already been released.
- Developers can build the compiler and standard library locally with Bazel using
./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo, and run standard-library tests from source. - Modular does not yet accept external patches to the compiler and tooling, although it has accepted standard-library contributions since 2024 and says it aims to open compiler contributions by year-end.
- For MAX kernel or model customization, users still need a prebuilt Mojo compiler;
--config=prebuilt-mojodownloads the latest nightly compiler instead of compiling it locally.
Hacker News opinions
I would call this source available today, with upstream contribution acceptance promised for early next year. Apache 2 lets me fork and modify it now, but the closed compiler had been a dealbreaker for many people. The question is whether Mojo can still gain traction.
I disagree with calling it source available. The OSI definition is about freely modifying and distributing source, not whether maintainers accept upstream patches.
Exactly. Apache 2 is an OSI-approved license, so this is open source even if the project does not accept random upstream contributions. SQLite has a similarly restrictive contribution model, and I have been waiting to try Mojo.
I have used Mojo intermittently for side projects for two years. Its ownership model resembles Rust, comptime resembles Zig, and I find its LLVM use and optimization work especially interesting.
The docs seem to say dependent types are not first class. It may be closer to refinement types, but for numerical work Mojo still feels less burdensome than Python, Julia, Matlab, R, Rust, C, or C++.
Without Windows support, Mojo will likely remain limited to a niche of experienced developers for a while. Python is not losing its position soon.
The closed source compiler was the main reason I had not tried Mojo. I want practical getting-started material and an answer on NumPy or SciPy-style work.
NuMojo is currently the nearest NumPy-like project, though it is still developing toward that goal. mojolang.org is a useful starting point, and the community repository lists more packages.
A permissive license without immediate upstream contributions may become a common model, similar to SQLite. It also filters out a flood of AI-generated patches while the Mojo team keeps language design control.
Mojo's linear types are deeply tied to manual memory management. Combined with its origin system, they make explicit pointer work safer while retaining flexibility.
Qualcomm's acquisition makes me wonder whether this is about commoditizing a complement. I am curious whether Mojo could affect Nvidia's position at all.
I like that Modular opened the standard library first, then kernel code and tools, before releasing the compiler. A small design team can keep a language coherent while public proposals and feedback still correct blind spots.
I am concerned that Qualcomm's acquisition could end in acqui-death. The open source release does not remove that risk.
I reviewed Mojo recently from the narrow angle of Python compatibility. It was not yet Python, and I want to revisit it without making Python compatibility the test.