Motoko versus Rust

Rust is a general-purpose systems language, and the network supports it through a canister development kit. The documentation describes the CDK as providing the macros and types a canister needs: the entry points, the caller context, the inter-canister call interfaces, and the stable structures. A Rust canister is a WebAssembly module compiled from ordinary Rust with those additions.

The consequence of using a general-purpose language is that persistence is explicit. The documentation describes stable structures — stable vectors, logs, cells, maps and sets — that store their data in stable memory directly, and the pre-upgrade and post-upgrade hooks for the case where state lives in the heap. A Rust developer decides where each piece of state lives, and the compiler does not enforce that the decision is correct.

The advantage is the ecosystem. Rust has mature libraries for parsing, cryptography, data structures and serialisation, and a canister can use them. The documentation also notes that Rust's memory model and the absence of a garbage collector make the resource profile more predictable, which matters when a canister's cycles budget is a real constraint.

Persistence is the first axis. A Motoko canister is harder to break by forgetting an upgrade hook, because the runtime carries the responsibility. A Rust canister is easier to break that way, and the documentation's guidance to test upgrades against production state applies most sharply there. A developer who values a smaller correctness surface may prefer Motoko for that reason alone.

Memory management is the second. The documentation describes Motoko's garbage collector as managing the heap, which is convenient but has a cost in cycles and in predictability. Rust has no garbage collector, so a developer controls allocation and deallocation explicitly. For a canister with a tight cycles budget or a large working set, that control can matter more than the convenience.

Ecosystem is the third. A project that needs a specific library, a particular cryptographic primitive, or an existing Rust codebase will find Rust the practical choice. A project that is starting fresh and wants the platform's idioms will find Motoko the shorter path. The documentation supports both and does not rank them.

The two languages are not isolated from each other. A canister's public interface is defined by Candid, the network's interface description language, and the documentation describes Candid as the contract that lets a Motoko canister call a Rust canister and the reverse. The caller does not need to know what language the callee was written in.

That means a project can use both. A team might write the performance-critical canister in Rust and the rest in Motoko, or reuse an existing Rust library in one canister while the others are Motoko. The documentation presents Candid as the boundary that makes this a normal engineering decision rather than a migration.

The documentation also notes that the Candid interface is what a frontend uses to call a canister, and that the interface can be fetched from a running canister or generated from source. The canisters page covers the message model and the interface that carries it.