Motoko 2.0.0: Persistent Actors and Safer Canister Upgrades

Motoko 2.0.0 is less a routine compiler update than a new upgrade contract for Internet Computer canisters. The release makes actors persistent by default: fields in a bare actor or actor class survive an upgrade unless they are declared transient. Teams that previously relied on transient-by-default behavior must review actor state and mark reset-on-upgrade fields explicitly.

The release also removes classical 32-bit orthogonal persistence from moc. New builds target enhanced orthogonal persistence with persistent 64-bit main memory and incremental garbage collection. This aligns the compiler with the Internet Computer’s current persistence model, in which compatible program memory can be retained across upgrades instead of being reconstructed through the older serialization path.

Existing classical canisters are not stranded, but their first upgrade into enhanced orthogonal persistence is a one-time migration. Motoko’s release notes require that upgrade to be compiled with --enhanced-orthogonal-persistence and without --enhanced-migration; later upgrades need neither flag. The migration is irreversible. Caveat: this transition should be rehearsed against a copy of production state and backed by a recovery path, because the official documentation recommends thorough upgrade testing and warns against configurations that can drop Wasm main memory.

The compatibility surface is broader than persistence. Motoko 2.0 promotes several diagnostics from warnings to errors, including non-exhaustive patterns, accidental Any or None inference, constant-result comparisons, malformed enhanced-migration files, bare imported declarations, and actor classes that omit an async return type. It also removes ExperimentalStableMemory in favor of Region and treats flexible as an ordinary identifier rather than a persistence modifier.

There are ergonomic changes too: if, while, switch, and for heads can omit parentheses; switch cases accept lighter pattern syntax; and the ?? operator now depends on whitespace. These changes may look cosmetic, but they can expose latent parsing or type-checking assumptions during a migration.

The practical release workflow is therefore compiler-first: pin moc 2.0.0 in a branch, run the v1-to-v2 migration guide, compile every canister, classify new errors, and test upgrades with representative state. Developers should also verify Candid and stable-state compatibility before deployment. Enhanced persistence can reject incompatible state changes and roll back the upgrade, but that safety mechanism does not remove the need to understand which fields are meant to survive.

Motoko 2.0.0’s headline is persistence by default. Its deeper change is that upgrade behavior is now more explicit: state ownership, migration intent, and previously tolerated mistakes must be visible in source and build checks.