Motoko Features

Aside from important developer productivity features such as subtyping, garbage collection, as well as arbitrary precision arithmetic, Motoko offers a host of useful features. Let’s have a look at these features in the following.

The Internet Computer’s canister smart contracts are natively supported by Motoko. Such a canisters is expressed in Motoko as a Motoko actor.

You can use the Motoko Playground to run the code.

Canisters send asynchronous messages to communicate with other canisters. With the help of Motoko, developers can write asynchronous code in sequential style. Asynchronous messages on the Internet Computer our function calls returning a future. As a result, developers can use the await construct to suspend execution until the completion of the future.

You can use the Motoko Playground to run the code.

Developers familiar to popular programming languages such as JavaScript will find Motoko intuitive. In comparison to other popular languages, Motoko offers features that include the following:

You can use the Motoko Playground to run the code.

The type interface a Motoko actor presents to its clients is a suite of named functions that include argument as well as (future) result types. This interface is emitted by the Motoko compiler (and SDK) in a language neutral format which is called Candid. This allows other canisters and apps with Candid support to use the services of the Motoko actor.

Motoko can also seamlessly interact with Candid-supported canisters that are implemented in other languages.

If we revisit the previous example, we can see that the Motoko Counter actor has this Candid interface:

The state of a Motoko actor survives indefinitely. This is made possible because the canister’s memory and other states are persisted as it executes. As a result, developers do not need to explicitly store/save the actor state with every message.

The following example shows how the state of the canister’s hash table is being preserved across calls despite the actor state being replicated across many nodes:

You can use the Motoko Playground to run the code.

Orthogonal persistence can be leveraged by developers in different ways, for example in the case of language features that retain a canister’s data while the canister’s code is being upgraded. This is accomplished in Motoko by declaring variables as stable which automatically preserves their variables across canister upgrades.

This can be better illustrated with the following example of a stable counter:

You can use the Motoko Playground to run the code.

The stable calendar can be installed, incremented, and upgraded without an interruption:

You can use the Motoko Playground to run the code.

You can see in the example above that value was declared stable. As a result, the current state is retained after upgrading.