Version: 1.1.0

Mojo vision

Mojo exists because AI hardware no longer looks like one CPU. Datacenters and devices mix chips from many vendors, and each chip arrives with its own software stack.

The aim is one language that can target those chips: CPUs, GPUs, and custom accelerators. Mojo already compiles for CPUs and for GPUs from more than one vendor. Covering every accelerator people will ship is the remaining work.

This page is the direction, not a schedule. The schedule-shaped document is the roadmap.

What Mojo is for

Modular's stated mission is to make AI compute available to more people, on more hardware. Mojo is the programming tool for that mission.

• One language instead of a split across Python, C++, Rust, and CUDA
• One set of tools that can reach each vendor's chip
• A path that starts easy and adds control when a kernel needs it

Why a new language

Extending C++, Rust, or Python was considered. Those languages were not designed around new numeric formats, explicit memory hierarchies, or the metaprogramming a kernel library needs. An embedded DSL keeps the host grammar and inherits its tooling limits.

A new language is expensive. It is also the option that can change the grammar when the hardware requires it.

Design principles

Mojo stays in the Python family: indentation, if and for, lists and dictionaries, and a small core. Deviations need a reason tied to performance or safety.

Kernel code has to scale across dtypes and chips without a hand-written copy for each pair. Compile-time parameters are how one source specializes.

The language is a systems language. Types are static. Copies and destruction are visible. Inner loops should not pay for a feature they do not use.

Complexity is the long-term risk. Features have to compose, and syntactic sugar waits until the core is stable. Modular's own codebase is the largest user, which is what keeps unused ideas out.

Architecture

Three bets carry the implementation:

1. Parametric metaprogramming, so a matrix multiply can specialize without a combinatorial library of kernels. 2. MLIR Core, the compiler toolkit underneath Mojo. The surface language is a way to build that IR, including inline dialect operations when needed. 3. Integration with MAX, so a kernel can be fused and transformed by the graph compiler instead of only launched as a black box.

Ahead

The language is one piece. Tools, libraries, and the people writing them decide whether Mojo is useful. The invitation is the same as on the home page: join the community and build with it.