On August 11, 2026, Modular released v1.0.0, the official version of its programming language "Mojo." Combining Python-like ergonomics with the control of a systems language, Mojo's vision of handling diverse computing resources—CPUs, GPUs, ASICs—within a single language has reached a stage where compatibility can be promised. However, the version number "1.0" does not mean the entire language environment is fully complete. Stability guarantees are limited to explicitly marked APIs, and homework remains regarding the ABI, toolchain, and open-sourcing of the compiler.
What Stable 1.0 Has Fixed
The biggest change Mojo 1.0 brings to developers isn't a set of new syntax features, but rather the establishment of a criterion for judging what won't break. Among language features and standard library components, APIs explicitly marked "stable" now follow semantic versioning. This is a promise that code depending on stable targets will maintain source compatibility across updates within the same major version.
Not the entire standard library was fixed from the start. Traits that are fully stable include Deinitable, Movable, Copyable, and ImplicitlyCopyable, while Array, List, Span, String, Bool, and Optional have begun stabilization only for some of their APIs. Features not marked stable in the API reference remain subject to change going forward.
What's guaranteed is source code compatibility—Mojo's ABI is not yet stable. Even the stability policy document itself is described as provisional, and exceptions may apply if significant issues are discovered. Teams planning for long-term operation need to check the stability status of each API they use, in addition to updating to mojo==1.0.0.
This official release also included more breaking changes than usual. Modular states that it has prepared deprecated aliases and compiler fix-its for nearly all changes, allowing migration to proceed mechanically. Rather than being the moment changes stopped, 1.0 marks the boundary where a major cleanup was completed and compatibility management began going forward.
Breaking Changes Align the Language's Boundaries
In the area of memory handling, Pointer and UnsafePointer have been unified into a single type. The design shifted from placing danger on the entire type to attaching unsafe_ to individual operations, such as reads and writes that skip bounds checking. Old names remain as deprecated, so existing code can migrate without needing to be rewritten all at once.
Lifetime checking gained an experimental feature called "interior origins" that tracks references inside containers. For example, if you hold a reference to an element of a List and then execute append() or pop()—operations that could trigger reallocation—the compiler will reject the code at the point where it tries to use that reference later. This mechanism stops dangling references before they occur at runtime, though the roadmap also explicitly notes that some situations are not yet safe by default.
Developers coming from Python gain lambda expressions, allowing single-expression anonymous closures. Meanwhile, in Python interoperability, arithmetic, comparison, and containment checks on PythonObject now directly use CPython's abstract protocols. According to official measurements, execution paths involving repeated a + b or a < b operations became about 12 times faster. This is not an improvement in Mojo's overall performance versus Python, but rather an improvement narrowly focused on the call boundary between languages.
The division of roles between Mojo and MAX has also become clearer. Some accelerator-oriented APIs have moved to a newly established max package, and layout is now bundled on the MAX side. Int and UInt, whose widths can differ between host and device, can no longer be passed to GPU kernels; fixed-width types like Int32 must be used instead. Precisely because Mojo aims to support heterogeneous hardware, implicit assumptions that would break portability were separated out in 1.0.
The Path to a General-Purpose Language Continues in Phase 2
On Mojo's roadmap, Phase 1—covering high-performance CPU and accelerator code—has been completed, and Phase 2, which expands the scope to systems applications, is currently underway. In other words, 1.0 marks the milestone where the foundation for high-performance kernels and Python extensions has solidified. It is not a declaration that Mojo can already replace, at the same level of maturity, the broad range of applications handled by Rust or C++.
Items not yet started include first-class async, algebraic data types and pattern matching, and access control. Initial support for distributed processing across multiple machines and package management are also still ahead. The LSP and VS Code extension are under development. Work continues on testing, benchmarking, and debuggers, while the profiler is described as not yet started.
There are also boundaries in Mojo's relationship with Python. While Mojo adopts Python-like syntax and provides an entry point for speeding up existing Python code, at present it does not aim for full compatibility with untyped Python-style code or Python libraries. Dynamic object-oriented features such as classes and inheritance fall within the scope of Phase 3, which has not yet begun. Whether Mojo will eventually become a complete Python superset also remains undetermined.
For developers, the realistic entry point is not replacing an entire Python application, but rather moving performance-critical processing or GPU kernels to Mojo. Combined with MAX, that code can then be connected to graph optimization and inference runtimes. 1.0 makes this narrowly defined strength maintainable, but expanding into general application development will require waiting for progress on Phase 2.
Openness Put to the Test Under Qualcomm
Qualcomm completed its acquisition of Modular on July 29, 2026. In its announcement, it stated it would continue Mojo, MAX, and Modular Cloud as products and brands, and maintain its stance toward an open, heterogeneous computing ecosystem spanning CPUs, GPUs, NPUs, and custom silicon. Mojo 1.0 is the first major language release to arrive after that policy statement.
The already-public modular/modular repository includes the Mojo standard library, MAX's CPU and GPU kernels, and code examples. While contributions to the repository are handled under the Apache License 2.0 with LLVM Exceptions, use and distribution of Mojo and MAX also involve the Modular Community License. The question of whether users can independently verify, port, and maintain the language implementation over the long term is not settled simply by the standard library being public.
The major remaining move is the release of the Mojo compiler. The official roadmap identifies the completion of Phase 1 as an appropriate point for release, and the official Mojo website also indicates that open-sourcing is near. However, as of August 12, completion of the compiler release cannot be confirmed. In a Q&A reported by The Register, Chris Lattner stated that NVIDIA and AMD remain strong partners and that he doesn't anticipate problems—but vendor neutrality can only truly be measured once outside parties can verify the implementation and licensing for themselves.
Mojo 1.0 has stepped from the stage of experimenting with a language for heterogeneous computing into a stage of maintaining it while choosing what to depend on. The next piece of evidence to watch for is under what conditions the compiler's source and build process will be released, and how far outside developers will be able to bring changes to backends targeting hardware beyond Qualcomm's own.