{"slug": "mojo-roadmap", "title": "Mojo Roadmap", "summary": "Modular has published a roadmap for the Mojo programming language, outlining its evolution from a prototype kernel DSL to a high-performance language for CPU and GPU coding, with plans to open-source the compiler at the end of Phase 1. The roadmap emphasizes long-term vision over short-term wins, focusing on expressiveness, error messages, and compile times.", "body_md": "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).\n\n# Mojo roadmap\n\nThis page provides a high-level roadmap of how we expect the Mojo programming\nlanguage to evolve over a series of phases. This roadmap provides **directional\nguidance** (not an engineering plan) and is **subject to change**. As we build,\nlearn, and expand Mojo's use cases, we will iterate, adapt, and invest wherever\nnecessary to unblock priorities.\n\nWe also periodically share roadmap updates in the [Modular forum\nannouncements section](https://forum.modular.com/c/modular/announcements/9).\n\n## Mojo's north star\n\nAs described in the [Mojo vision](/docs/vision/), we created Mojo to unite\ndevelopers with a single language that provides ergonomic programming features\nfor accelerator hardware and that scales to solve other challenges in AI and\nsystems programming.\n\nOur goals are ambitious and we're taking on challenges that many languages and\nsystems have struggled with for decades. We believe Mojo has the right blend of\n**technology, design principles, and community-first philosophy** to succeed,\nbut it'll work only if we stay focused and make deliberate tradeoffs aligned\nwith our long-term vision.\n\nThe stakes are high—programming languages that succeed shape entire ecosystems,\nsupport millions of developers, and define how software is built. That means we\nmust **resist the urge to chase short-term wins** at the expense of long-term\nclarity, consistency, and quality.\n\nOur 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.\n\nWe know the path won't be perfect and we'll make mistakes. But with a\nstrong foundation and an engaged, thoughtful community, we can **learn,\niterate, and improve together**.\n\n## Phase 0: Initial bring-up\n\nPhase 0 focused on foundational language work: implementing the core parser, defining memory types, functions, structs, initializers, argument conventions, and more.\n\nAs 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.\n\n## Phase 1: High performance CPU + GPU coding\n\nPhase 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.\n\nBut performance alone isn't enough. We're equally focused on:\n\n**Expressiveness** for building robust libraries**Good error messages** for developer productivity**Fast compile times** to support iteration speed\n\nThe conclusion of phase 1 is the natural point to **open source the Mojo\ncompiler**.\n\n### Generics and metaprogramming features\n\nThe backbone of phase 1 is Mojo's **metaprogramming system**, combined with\na **modern generic type system** that catches errors at compile time, before\ncode is instantiated. The following features capture how we think Mojo should\nevolve, but may change as we grow into them:\n\n-\n✅\n\n**Compile-time constructs**: The parameter system, compile-time interpreter,`if`\n\nand`for`\n\nloops, etc. -\n✅\n\n**Trait unions:** Allow`Copyable & Defaultable`\n\nintersections for precise trait conformance. See the[trait composition proposal](https://github.com/modular/modular/blob/mojo/v1.0.0b2/mojo/proposals/trait_composition.md). -\n✅\n\n**Predictable dependent types:** Support advanced parametric algorithms while avoiding rebinding. -\n✅\n\n**Parametric comptime values:** Compute parametric values, going beyond types and functions. See the[parametric aliases proposal](https://github.com/modular/modular/blob/mojo/v1.0.0b2/mojo/proposals/parametric_alias.md). -\n✅\n\n**Default trait methods**: Enable static composition (mixin-style). -\n✅\n\n**Parametric raises**: The ability to throw types other than`Error`\n\nand therefore support higher order functions like`map`\n\nthat propagate the \"raisability\" of their closure argument. -\n✅\n\n**Closure refinement**: Unified representation for compile-time/runtime closures. -\n✅\n\n: Enable early constraint checking and better error messages for generics. See the`where`\n\nclauses[where clauses proposal](https://github.com/modular/modular/blob/mojo/v1.0.0b2/mojo/proposals/where_clauses.md). -\n✅\n\n**Conditional conformance**: Allow trait conformance based on predicates over parameters. -\n🚧\n\n**Struct extensions**: Post-hoc type extension and better modular refactoring. See the[struct extension proposal](https://github.com/modular/modular/blob/mojo/v1.0.0b2/mojo/proposals/struct-extensions.md). -\n✅\n\n**Linear types/explicitly-destroyed types**: Create types that require an explicit call to deinitialize a value at end of its lifetime. -\n🚧\n\n**Stabilization markers**: Mechanism to tag standard library APIs with maturity levels.\n\n### Python interoperability\n\nWe 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:\n\n-\n✅\n\n**Build integration**: Seamless connection between Mojo's build system and Python packaging. -\n✅\n\n**Python export**: Support for exposing functions and initializers to Python.\n\n### Core language usability and ergonomics\n\nMojo should \"just work\" for core Python-like tasks, while offering the control systems programmers expect:\n\n-\n✅\n\n**Basic constructs**: Functions, structs, control flow (`if`\n\n,`for`\n\n, etc.). -\n✅\n\n**Literal support**: Infinite-precision`int`\n\n/`float`\n\n, collections, comprehensions. -\n🚧\n\n**Collections**: Round out core types like`List`\n\n,`Dict`\n\n,`Iterator`\n\n,`SIMD`\n\n,`String`\n\n, etc., to utilize the language feature set of phase 1. For instance, see[making SIMD comparable](https://github.com/modular/modular/blob/mojo/v1.0.0b2/mojo/proposals/simd-comparable.md)and the[string type proposal](https://github.com/modular/modular/blob/mojo/v1.0.0b2/mojo/proposals/string-design.md). -\n✅\n\n**Unsafe programming**: Refine`UnsafePointer`\n\nand low-level primitives. -\n🚧\n\n**Variadic args**: Full support for`*args`\n\n,`**kwargs`\n\n. -\n⬜\n\n**Lambda syntax** for inline closure declarations. -\n⬜\n\n**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.- 🚧 Mojo Language Server Protocol support and VSCode Extension\n- 🚧 Testing Framework\n- ⬜ Benchmarking framework\n- 🚧 Debugger\n- ⬜ Profiler\n- ⬜ Packaging and build system\n\n-\n🚧\n\n**GPU programmability abstractions**: Rich and easy to use abstractions for a tensor type, data layout, and basic algorithms.\n\n### Syntax and surface language polish\n\nThese may seem small, but they significantly impact developer ergonomics and reduce future source incompatibilities:\n\n-\n✅\n\n**Argument conventions**: Refine`init`\n\n/`del`\n\nbehaviors, naming, and default conventions. -\n✅\n\n**Literal refinements**: Improve reliability of infinite precision literals using dependent types. See the[collection literal design](https://github.com/modular/modular/blob/mojo/v1.0.0b2/mojo/proposals/collection-literal-design.md)and[fixing simple literals proposal](https://github.com/modular/modular/blob/mojo/v1.0.0b2/mojo/proposals/fixing-simple-literals.md). -\n🚧\n\n**Attribute macros**: Replacing ad-hoc constructs like`@__nonmaterializable`\n\n,`@value`\n\n, etc., using traits and other existing language features (shrinking the language). For instance, see the[upgrading \"trivial\" proposal](https://github.com/modular/modular/blob/mojo/v1.0.0b2/mojo/proposals/upgrading-trivial.md)and[upgrading](https://github.com/modular/modular/blob/mojo/v1.0.0b2/mojo/proposals/upgrading-value-decorator.md).`@value`\n\ndecorator\n\n### Non-goals\n\nWe are intentionally *not* pursuing the following in phase 1:\n\n-\n**Syntax sugar**: We defer most sugar until the core language is stable and composable. -\n**Untyped Python-style code**: For now, explicit`PythonObject`\n\ntype annotations are required. -\n**Python library parity**: We expect there will be many missing APIs (e.g. potentially file system APIs) in phase 1.\n\n## Phase 2: Systems application programming\n\nOnce 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++.\n\nThat said, **we are not aiming to match Rust or C++ feature-for-feature**. Our\ngoal is to keep Mojo a relatively small and teachable language—one that solves\nspecific problems [without unnecessary\ncomplexity](/docs/vision/#managing-language-complexity).\n\n### Language and abstraction features\n\n-\n**First-class** Fully integrated with Mojo's type and memory models.`async`\n\nsupport: -\n**Existentials / dynamic traits:** For building flexible runtime abstractions. -\n**Richer metatypes:** Extending support for type-level programming. -\n**Algebraic data types & pattern matching:** Enabling expressive state modeling. -\n**Dynamic reflection features.** -\n**Initial distributed programming support.**\n\n### Memory safety model: fast, expressive, gradual\n\nMojo code should be memory-safe by default, while still being fast, expressive,\nand gradually more complex for beginners. Although phase 1 provides a strong\nframework for [memory safety](/docs/manual/values/), there still exist\nsituations where safety is not guaranteed by default and we expect won't be\nfully resolved until phase 2.\n\n-\n**Fast:** Mojo should enable the programmer to write high-performance memory-safe code by default, while continuing to provide unsafe primitives for expert use. -\n**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. -\n**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.\n\nThis will likely require:\n\n-\nFinalize indirect origins.\n\n-\nSupport mutable aliasing of struct fields.\n\n-\nSupport mutable aliasing of function arguments.\n\n-\nPrevent dereferencing any references to fields of deallocated reference-counted objects.\n\n-\nAccess control features, e.g.\n\n`private`\n\nmodifiers (or formalizing the underscore convention) to prevent violating abstraction boundaries. -\nEliminate undefined behavior, especially in core types and built-in operations.\n\nThis 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.\n\n### Other application-level programming features\n\nWe might explore hygienic, importable macros to extend Mojo's surface syntax in\ncontrolled ways. For example, enable constructs like `parallel_for`\n\nthat feel\nas seamless as a built-in `for`\n\nloop but that are defined in libraries.\n\nWe also might explore making the Mojo optimizer extensible with \"library\ndefined\" optimizations. For example, allow Mojo library authors to define\nrewrites like `String.__add__(x, String.__add__(y, z))`\n\ninto `String.concat(x, y, z)`\n\n. The exact shape and ultimate capability of this will be defined later.\n\n## Phase 3: Dynamic object oriented programming\n\nEventually, 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.\n\nAs 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.\n\nWe'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.\n\n## Continuous investments\n\nThe following topics will remain in progress throughout Mojo's lifetime and are not tied to any specific phase:\n\n-\n**Error messages and diagnostics**: Always room for improvement, but parameter inference and elaborator errors need improvement in particular. -\n**Compile times**: We will continue pushing for faster developer iteration cycles. -\n**Standard library cleanup**: API consolidation, regularization, and new capabilities. -\n**Hardware support**: Extending Mojo's backend to support new architectures.\n\n## Contributing to Mojo\n\nWe'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.\n\nHowever, 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.\n\nYou can learn more about contributing to the standard library from the contributor doc below:\n\nIf you encounter any bugs with Mojo, please\n[submit an issue on GitHub](https://github.com/modular/modular/issues).", "url": "https://wpnews.pro/news/mojo-roadmap", "canonical_source": "https://mojolang.org/docs/roadmap/", "published_at": "2026-07-01 02:57:03+00:00", "updated_at": "2026-07-01 03:50:11.141779+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure"], "entities": ["Modular", "Mojo"], "alternates": {"html": "https://wpnews.pro/news/mojo-roadmap", "markdown": "https://wpnews.pro/news/mojo-roadmap.md", "text": "https://wpnews.pro/news/mojo-roadmap.txt", "jsonld": "https://wpnews.pro/news/mojo-roadmap.jsonld"}}