Mojo roadmap

This page provides a high-level roadmap of how we expect the Mojo programming language to evolve over a series of phases. This roadmap provides directional guidance (not an engineering plan) and is subject to change. As we build, learn, and expand Mojo's use cases, we will iterate, adapt, and invest wherever necessary to unblock priorities.

We also periodically share roadmap updates in the Modular forum announcements section.

Phases

The phases below are conceptual groups of work—not version numbers—and they have no timeline for completion. We haven't yet established a long-term versioning scheme, finalized our approach to language evolution, or decided what "stability" will mean or when it will happen.

Work items

An empty box ⬜ indicates work that's not started, a barricade 🚧 is for work in progress, and a checked box ✅ means it's done. However, this is not an exhaustive list of work and the status might be out of date. Also, the items in each list aren't necessarily ordered by priority and some items may be "nice to have" and not required to complete the phase.

Mojo's north star

As described in the Mojo vision, we created Mojo to unite developers with a single language that provides ergonomic programming features for accelerator hardware and that scales to solve other challenges in AI and systems programming.

Our goals are ambitious and we're taking on challenges that many languages and systems have struggled with for decades. We believe Mojo has the right blend of technology, design principles, and community-first philosophy to succeed, but it'll work only if we stay focused and make deliberate tradeoffs aligned with our long-term vision.

The stakes are high—programming languages that succeed shape entire ecosystems, support millions of developers, and define how software is built. That means we must resist the urge to chase short-term wins at the expense of long-term clarity, consistency, and quality.

Our approach is to keep short-term development focused and anchored on measurable outcomes, while building for generality so Mojo can eventually become a general-purpose language spanning CPUs, GPUs, and other hardware, plus the myriad of applications that Python is used for.

We know the path won't be perfect and we'll make mistakes. But with a strong foundation and an engaged, thoughtful community, we can learn, iterate, and improve together.

Phase 0: Initial bring-up

✅

COMPLETE

Phase 0 focused on foundational language work: implementing the core parser, defining memory types, functions, structs, initializers, argument conventions, and more.

As development accelerated, multiple libraries emerged to fill immediate needs, often overlapping in functionality (e.g., multiple pointer types). As the language stabilized, we consolidated these libraries into a coherent and consistent foundation.

Phase 1: High performance CPU + GPU coding

🚧

IN PROGRESS

Phase 1 takes Mojo from a "prototype kernel DSL" to a viable foundation for real-world accelerated compute workloads. This phase focuses on making Mojo a powerful and expressive language for writing high-performance kernels on CPUs, GPUs, and ASICs. We also want to unlock other performance use-cases for CPUs, particularly the ability to extend Python packages in a seamless way.

But performance alone isn't enough. We're equally focused on:

Expressiveness for building robust libraries
Good error messages for developer productivity
Fast compile times to support iteration speed

The conclusion of phase 1 is the natural point to open source the Mojo compiler.

Generics and metaprogramming features

The backbone of phase 1 is Mojo's metaprogramming system, combined with a modern generic type system that catches errors at compile time, before code is instantiated. The following features capture how we think Mojo should evolve, but may change as we grow into them:

✅ Compile-time constructs: The parameter system, compile-time interpreter, if and for loops, etc.
✅ Trait unions: Allow Copyable & Movable intersections for precise trait conformance. See the trait composition proposal.
✅ Predictable dependent types: Support advanced parametric algorithms while avoiding rebinding.
✅ Parametric aliases: Compute parametric values, going beyond types and functions. See the parametric aliases proposal.
✅ Default trait methods: Enable static composition (mixin-style).
🚧 Closure refinement: Improve capture modeling and unify compile-time/runtime representations.
🚧 requires clauses: Enable early constraint checking and better error messages for generics. See the requires clause proposal.
🚧 Conditional conformance: Allow trait conformance based on predicates over parameters.
🚧 Struct extensions: Post-hoc type extension and better modular refactoring. See the struct extension proposal.
🚧 Linear types: Support ownership patterns; blocked on conditional conformance.
⬜ Stabilization markers: Mechanism to tag standard library APIs with maturity levels.
⬜ Parametric raises: The ability to throw types other than Error and therefore support higher order functions like map that propagate the "raisability" of their closure argument.

Python interoperability

We want Mojo to be an approachable way to extend and speed up existing Python code. We'd like to incorporate the key features of popular libraries like "nanobind" as a guideline:

✅ Build integration: Seamless connection between Mojo's build system and Python packaging.
🚧 Python export: Support for exposing functions and initializers to Python.
⬜ Debugger/LSP support for mixed Python/Mojo applications.

Core language usability and ergonomics

Mojo should "just work" for core Python-like tasks, while offering the control systems programmers expect:

✅ Basic constructs: Functions, structs, control flow (if, for, etc.).
✅ Literal support: Infinite-precision int/float, collections, comprehensions.
🚧 Collections: Round out core types like List, Dict, Iterator, SIMD, String, etc., to utilize the language feature set of phase 1. For instance, see making SIMD comparable and the string type proposal.
🚧 Unsafe programming: Refine UnsafePointer and low-level primitives.
🚧 Variadic args: Full support for *args, **kwargs.
⬜ Lambda syntax for inline closure declarations.
⬜ Stable and robust toolchain: Cross-compilation, packaging and build system, testing and benchmarking framework in the standard library, debugger, profiler etc. We expect to make a big dent on this, but won't fully complete everything interesting in this space in phase 1.

Syntax and surface language polish

These may seem small, but they significantly impact developer ergonomics and reduce future source incompatibilities:

✅ Argument conventions: Refine init/del behaviors, naming, and default conventions.
✅ Literal refinements: Improve reliability of infinite precision literals using dependent types. See the collection literal design and fixing simple literals proposal.
🚧 Attribute macros: Replacing ad-hoc constructs like @register_passable("trivial"), @nonmaterializable, @value, etc., using traits and other existing language features (shrinking the language). For instance, see the upgrading "trivial" proposal and upgrading @value decorator.

Non-goals

We are intentionally not pursuing the following in phase 1:

Syntax sugar: We defer most sugar until the core language is stable and composable.
Untyped Python-style code: For now, explicit PythonObject type annotations are required.
Python library parity: We expect there will be many missing APIs (e.g. potentially file system APIs) in phase 1.

Phase 2: Systems application programming

⏰

NOT STARTED

Once the core generic type system and systems programming features converge and stabilize, we'll begin expanding Mojo to support application-level programming—the kinds of problems typically addressed with languages like Rust and C++.

That said, we are not aiming to match Rust or C++ feature-for-feature. Our goal is to keep Mojo a relatively small and teachable language—one that solves specific problems without unnecessary complexity.

None of the features below are currently scoped, and we aren't interested in design discussions about them. We list them here so we can understand non-goals for phase 1 and rationalize how things add up over time. Our focus remains firmly on completing phase 1 before investing significant effort here.

Language and abstraction features

First-class async support: Fully integrated with Mojo's type and memory models.
Existentials / dynamic traits: For building flexible runtime abstractions.
Richer metatypes: Extending support for type-level programming.
Algebraic data types & pattern matching: Enabling expressive state modeling.
Dynamic reflection features.
Initial distributed programming support.

Memory safety model: fast, expressive, gradual

Mojo code should be memory-safe by default, while still being fast, expressive, and gradually more complex for beginners. Although phase 1 provides a strong framework for memory safety, there still exist situations where safety is not guaranteed by default and we expect won't be fully resolved until phase 2.

Fast: Mojo should enable the programmer to write high-performance memory-safe code by default, while continuing to provide unsafe primitives for expert use.
Expressive: Mojo's origin system should enable more mutable aliasing to provide a more expressive programming model than languages like Rust. This is desirable because aliased mutable objects occur widely in both the Python and C++ communities, often for legitimate reasons of expressiveness, simplicity, and/or performance.
Gradual: We want progressive disclosure of complexity—it should be easy to get started and be immediately productive in Mojo, and users can gradually learn the more advanced features as they need them.

This will likely require:

Finalize indirect origins.
Support mutable aliasing of struct fields.
Support mutable aliasing of function arguments.
Prevent dereferencing any references to fields of deallocated reference-counted objects.
Access control features, e.g. private modifiers (or formalizing the underscore convention) to prevent violating abstraction boundaries.
Eliminate undefined behavior, especially in core types and built-in operations.

This will get us closer to the goal of making Mojo's memory safety model fast, expressive, and gradually more complex for beginners—making Mojo more approachable to Python and C++ developers.

Other application-level programming features

We might explore hygienic, importable macros to extend Mojo's surface syntax in controlled ways. For example, enable constructs like parallel_for that feel as seamless as a built-in for loop but that are defined in libraries.

We also might explore making the Mojo optimizer extensible with "library defined" optimizations. For example, allow Mojo library authors to define rewrites like String.__add__(x, String.__add__(y, z)) into String.concat(x, y, z) . The exact shape and ultimate capability of this will be defined later.

Phase 3: Dynamic object oriented programming

⏰

NOT STARTED

Eventually, we want Mojo to support the core dynamic features that make Python great, including support for untyped variables, classes, inheritance, etc. We have some thoughts about how these features will compose into the other features, but defer detailed planning and scoping until the earlier phases are done.

As Mojo matures through phase 3, we believe Mojo will become increasingly compatible with Python code and deeply familiar to Python users, except more efficient, powerful, coherent, and safe. Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't.

We're encouraged by how well AI-assisted coding tools already help migrate Python to Mojo today, and we're confident that future tooling and ecosystem maturity will make this evolution even smoother.

Continuous investments

The following topics will remain in progress throughout Mojo's lifetime and are not tied to any specific phase:

Error messages and diagnostics: Always room for improvement, but parameter inference and elaborator errors need improvement in particular.
Compile times: We will continue pushing for faster developer iteration cycles.
Standard library cleanup: API consolidation, regularization, and new capabilities.
Hardware support: Extending Mojo's backend to support new architectures.

Contributing to Mojo

We're committed to open-sourcing all of Mojo, but the language is still very young and we believe a tight-knit group of engineers with a common vision moves faster than a community-driven effort. So we will continue to plan and prioritize the Mojo roadmap within Modular until more of its internal architecture is fleshed out.

However, the Mojo standard library is already open sourced and we'd love to accept your contributions there. Although this roadmap mentions some standard library types because they depend on changes in the Mojo compiler, a lot of work on the standard library is not accounted for here.

You can learn more about standard library plans from the following docs:

If you encounter any bugs with Mojo, please submit an issue on GitHub.

Mojo's north star​

Phase 0: Initial bring-up​

Phase 1: High performance CPU + GPU coding​

Generics and metaprogramming features​

Python interoperability​

Core language usability and ergonomics​

Syntax and surface language polish​

Non-goals​

Phase 2: Systems application programming​

Language and abstraction features​

Memory safety model: fast, expressive, gradual​

Other application-level programming features​

Phase 3: Dynamic object oriented programming​

Continuous investments​

Contributing to Mojo​