Modular 26.6 is here: Mojo 1.1 opens the compiler to external contributions and adds developer experience improvements, while MAX 26.6 brings audio generation, new model architectures, and faster performance. Read more here.
Congrats!
Just a heads-up…Mojo 1.1 appears to have some breaking changes in it, so at minimum you’ll probably want to change the upper limit for Mojo in your pixi.toml:
# Had this in my packages, some of them broke
# [dependencies]
# mojo = ">=1.0.0,<2"
[dependencies]
mojo = ">=1.0.0,<1.1"
For the sake of my own understanding, could you please be more specific? what’s got broken after upgrade?
My sort dependent codes got broken because of this change:
-
-
The async task API is private:
std.runtime.asyncrtbecamestd.runtime._asyncrt. The publicstd.runtimekeeps onlyparallelism_levelandinitialize_runtime, and the docs say the async system “carries no stability guarantees” and is “deliberately not part of this package’s public API”. -
There is no public replacement.
std.algorithmhasmap,vectorize,tileandunswitch;mapis sequential (checked in the stdlib source,Mojo/stdlib/std/algorithm/backend/cpu/map.mojo). Nothing public instdruns a closure over work items on the thread pool. -
InlineArrayis gone;Arrayis the name, on 1.0 too. -
A
stattimespec’s sub-second field istv_subsecon 1.0 andtv_nsecon 1.1.
-
Sorry about the change in some of these interfaces, but there were good reasons for all of them. With 1.0, we had worked to stabilize the core of the language, but only a relatively small surface area of the Mojo standard library is currently marked as @stable. We are increasing this coverage over time, and will be doing so over the 1.x span. The library components marked as @stable can be built on with a high degree of confidence.
Given that much of what we think of as Mojo is defined at the library level, you can see changes impacting your code between point releases even though core language features themselves are stable. We’ll try to do our best to call those out in the changelog, and if we’re not communicating them as well as we could be, please let us know. Again, more of the standard library should be stabilizing as we progress through the 1.x series, but stability is a commitment and we need to carefully review each of these.
In your case, I want to highlight that the current async functionality in Mojo is not where we would like it to be and is a known area that will be fully revamped in the near term. That’s why we placed it behind the underscored interfaces you mention above: we wanted to convey that these interfaces may break, be reworked, or removed entirely in favor of something else. Anything with an underscore is something that is likely to change, so just know that going in when incorporating those into your projects. We unfortunately only caught these interfaces post-1.0, as part of our open-sourcing preparation, thus the migration you saw in 1.1.
No problem at all, I originally just wanted to point it out to everyone as the quick solution as they evaluated what the actual changes were ![]()