Timers and Base Library: Weekly Motoko Updates

Motoko Weekly Update Part 4!

Hey Motoko Devs,

Happy new year!

The languages team is back in 2023, hitting the ground running and picking up right where we left off last year. Before we move on, if you missed our last joint post with the SDK team, check it out here. As a recap, the languages team left off last year by focusing on testing and documenting large portions of the Motoko base library.

New Language Feature: Motoko Timers

Meet Motoko Timers! This is a new language feature that allows you to easily access the timers capability of the Internet Computer that lets you schedule asynchronous jobs for the future!

The most straightforward way to access this feature is through the Timer.mo base library, which exposes setTimer and recurringTimer.

setTimer : (d : Duration, job : () -> async ()) -> (id : Nat)
recurringTimer : (d : Duration, job : () -> async ()) -> (id : Nat)
cancelTimer : (id : Nat) -> ()

Use setTimer to schedule one-off jobs that get executed in the future, and recurringTimer to auto-repeat these jobs. The duration can be given in nanoseconds (or seconds if that is more convenient for you). Use cancelTimer to remove a previously set timer.

If you’re a power user that wants precise control over the canister’s global timer, you can define a system function called timer yourself, and establish either a super simple or an elaborately customized mechanism. If you want to avoid any timer-related code in your canister, you can pass the -no-timer flag to moc and stop paying for what you don’t use. See more details in the PR discussion here.

As a first customer, Motoko Playground will use timers to control canister expiration soon, but we expect many more use cases to come forth in the future!

This feature will be included in the next release of DFX, but is also available in the current release of the Motoko Compiler. Have fun with timers!

Base Library: Improved Documentation and Testing

The languages team was hard at work during the end of year and the start of this year, amongst other things, at testing and documenting the base library en masse! We’ve added a bunch of descriptions to the library functions, as well as runnable examples so devs can quickly figure out how to use the different APIs. We’ve also expanded the unit test coverage of these library modules to give developers a stronger level of confidence in our modules. We’ll be cutting a release of motoko-base soon to get these changes out to you guys, and will also continue to improve the documentation and testing of our libraries.

See you next time!

We’ll be back with more features and updates in a week’s time. Happy building and happy new year!

– DFINITY Languages team.


How ‘expensive’ is keeping this in? I’m guessing it is space in the wasm binary? Is it actually running something like a heartbeat that would use a high level of cycles?

1 Like

It shouldn’t be expensive in terms of cycles, as the canister_global_timer Wasm endpoint will never be called. I guess the extra bytecode is in the 1k range, but never quantified it actually. Can you? The flag is mostly there to remove unnecessary code from the Wasm, and reduce imports/exports for the security-minded.

Another quick update: interactive code snippets from Embed Motoko are now supported in this forum!


I would just like to express how much i appreciate these posts. Very helpful for clarity and updates