Mojo roadmap | Mojo
IMPORTANT: To view this page as Markdown, append `.md` to the URL (e.g. /docs/manual/basics.md).<br>For the complete Mojo documentation index, see llms.txt.<br>Skip to main content
Mojo will be open source soon! Join us at ModCon '26 for an update.
Version: 1.0.0b2On this page<br>For the complete Mojo documentation index, see llms.txt. Markdown versions of all pages are available by appending .md to any URL (e.g. /docs/manual/basics.md).<br>This page provides a high-level roadmap of how we expect the Mojo programming<br>language to evolve over a series of phases. This roadmap provides directional<br>guidance (not an engineering plan) and is subject to change . As we build,<br>learn, and expand Mojo's use cases, we will iterate, adapt, and invest wherever<br>necessary to unblock priorities.
We also periodically share roadmap updates in the Modular forum<br>announcements section.
Phases<br>The phases below are conceptual groups of work—not version numbers—and they<br>have no timeline for completion. Mojo now has versioned releases, but these<br>phases remain roadmap categories rather than release commitments. The status<br>markers below describe our current direction and may change as the language and<br>standard library evolve.
Work items<br>An empty box ⬜ indicates work that's not started , a barricade 🚧 is for<br>work in progress , and a checked box ✅ means it's done . However, this is<br>not an exhaustive list of work and the status might be out of date. Also, the<br>items in each list aren't necessarily ordered by priority and some items may be<br>"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<br>developers with a single language that provides ergonomic programming features<br>for accelerator hardware and that scales to solve other challenges in AI and<br>systems programming.
Our goals are ambitious and we're taking on challenges that many languages and<br>systems have struggled with for decades. We believe Mojo has the right blend of<br>technology, design principles, and community-first philosophy to succeed,<br>but it'll work only if we stay focused and make deliberate tradeoffs aligned<br>with our long-term vision.
The stakes are high—programming languages that succeed shape entire ecosystems,<br>support millions of developers, and define how software is built. That means we<br>must resist the urge to chase short-term wins at the expense of long-term<br>clarity, consistency, and quality.
Our approach is to keep short-term development focused and anchored on<br>measurable outcomes, while building for generality so Mojo can eventually<br>become a general-purpose language spanning CPUs, GPUs, and other hardware, plus<br>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<br>strong foundation and an engaged, thoughtful community, we can learn,<br>iterate, and improve together .
Phase 0: Initial bring-up
COMPLETE
Phase 0 focused on foundational language work: implementing the core parser,<br>defining memory types, functions, structs, initializers, argument conventions,<br>and more.
As development accelerated, multiple libraries emerged to fill immediate needs,<br>often overlapping in functionality (e.g., multiple pointer types). As the<br>language stabilized, we consolidated these libraries into a coherent and<br>consistent foundation.
Phase 1: High performance CPU + GPU coding
🚧<br>IN PROGRESS
Phase 1 takes Mojo from a "prototype kernel DSL" to a viable foundation for<br>real-world accelerated compute workloads. This phase focuses on making Mojo a<br>powerful and expressive language for writing high-performance kernels on CPUs,<br>GPUs, and ASICs. We also want to unlock other performance use-cases for CPUs,<br>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<br>compiler .
Generics and metaprogramming features
The backbone of phase 1 is Mojo's metaprogramming system , combined with<br>a modern generic type system that catches errors at compile time, before<br>code is instantiated. The following features capture how we think Mojo should<br>evolve, but may change as we grow into them:
✅ Compile-time constructs : The parameter system, compile-time<br>interpreter, if and for loops, etc.
✅ Trait unions: Allow Copyable & Defaultable intersections for precise<br>trait conformance. See the<br>trait composition proposal.
✅ Predictable dependent types: Support advanced parametric algorithms<br>while avoiding rebinding.
✅ Parametric comptime values: Compute parametric values, going beyond<br>types and functions. See the<br>parametric aliases proposal.
✅ Default trait methods : Enable static composition (mixin-style).
✅ Parametric raises : The ability to throw types other than Error...