Motoko 2024 Roadmap

Developers Motoko
1

Motoko 2024 Roadmap

:information_source: Note: this roadmap is still pending final approval and is subject to change.


Hi everyone. After a wonderful week in Zurich with the Languages team, we are ready to share our 12-month roadmap.

Themes

The work planned for Motoko, Candid, and all surrounding tooling is categorized by three distinct themes. The themes themselves were developed through careful review of user feedback and analysis of various trends within the ICP ecosystem.

DX + Productivity

By far the most important theme we’ve identified, and the one with the most work planned focuses on improvements to developer experience and developer productivity. This is all about ensuring Motoko is a joy to use day after day and that it meets the productivity needs of developers ranging from enthusiasts to professionals.

Base Library 2.0

We plan to rewrite a few common base library methods and provide abstractions around data structures like Set, Map, and List. We will also provide a better templating/blueprint system so the community can develop high-quality base library additions as well. We’d also like to introduce units to Time as requested by this Feedback Board topic.

FFI via Wasm Component Model

This is an exploration to learn how to support multi-language canisters using Wasi 2 and the Wasm component model specification. This can open the door to things like importing and using Rust crates directly in a Motoko program. Note this is already possible (with limitations) through the great work of @rvanasa using the Canpack tool.

VSCode Extension Enhancements

The community has a long wishlist of features they would like to see get added to the Motoko VSCode extension. We would like to address as many as we can.

Candid Type Selector

This feature brings an additional configuration layer to Candid that allows types to be mapped natively to and from host / destination languages, as well as a number of other improvements that will bring greater automation to your Candid-based workflows.

Canister Logging

This feature brings support for logging to Motoko with some additional sugar and capabilities on top.

Canister State Snapshots

This feature brings support for creating a snapshot of a canister’s state as well as rolling a canister back to a previously saved snapshot.

Exposing Best Effort Responses

With the introduction of call timeouts, we need to invent a new idiom that exposes this capability to Motoko developers in an easy-to-use and type-safe fashion. This new idiom will likely be applied to the way Cycles are added to calls as well.

Actor Mixins

This feature would introduce the ability to import an actor into a Motoko program that already has an actor defined.

Explicit Type Imports

This feature would introduce the ability to import a type by name.

Selectively Disabling Compiler Warnings

This feature would introduce a configurable filter that could be used to suppress certain compiler warnings.

Data Visualizer

This exploration would give us an opportunity to learn what is required to build efficient and scalable data visualization capabilities into Motoko programs. Developers could use this to inspect their Motoko state and understand how storage space is being used / allocated.

Scalability + Performance

As the name implies, this theme concentrates on bringing greater speed, storage, and efficiency to Motoko programs.

Enhanced Orthogonal Persistence

This feature introduces a fundamental change to the relationship between heap memory and stable memory. For developers, it means that state will persist indefinitely and across upgrades without needing to use stable memory APIs. The result will be a far simpler and more pleasant experience working with persistent data.

Self-describing Heap

This is a low-level feature that adds additional data to the memory representation of objects. It simplifies debugging, heap snapshot inspection, and data recovery.

Graph Copy

This is a means to enabling Enhanced Orthogonal Persistence. It offers a mechanism for flexibly changing the memory layout of a Motoko program.

Synthesis of Rust Deserialization Code

This is an exploration to determine how we can improve the performance of Candid parsing in a Rust program. We will look at static generation of deserialization code, which can potentially improve the performance of Candid parsing by 10x.

Correctness + Security

This theme is centered around helping developers write Motoko ICP smart contracts that are secure and bug-free through expansive compiler checking.

Try / Finally

This feature introduces a mechanism to define a cleanup block in a try / catch statement.

Asset Certification

We would like to bring an asset certification library to Motoko that has parity with the excellent ic-asset-certification crate developed by @NathanosDev. This would open the door to a asset canisters written in Motoko as well as myriad other community projects.

Conclusion

That sums it up. We hope you are as excited about the upcoming developments as we are. If you have any questions or comments, please discuss below!

cc @luc-blaeser @claudio @chenyan @ggreif @rvanasa

27 Likes
2

Could you elaborate more on the canister logging section, not sure i understand

3 Likes
3

If we achieve all of that in 2024, it would be amazing. I’m super interested in:

  1. Actor mixins.
  2. Enhanced Orthogonal persistence.
  3. Multi-language canisters.

Base Library 2.0 will definitely help with adoption, as there is currently a steep learning curve when entering the Motoko ecosystem.

7 Likes
4

Exciting stuff! Many thanks to the Motoko team and those supporting them in these efforts.

3 Likes
5

Really, really good roadmap.

Would be nice to have a round of feedback on the logging, snapshot, and best effort message Motoko API primitives before they’re locked in.

Excited for this!

3 Likes
6

Did you get permission from the DAO to update the language? My upcoming Yeetoko Dinosaurs project relies heavily on Motoko and it would be a shame if these changes gave me any additional hurdles.

image
image1242×1274 121 KB

2 Likes
7

Thanks for your hard working

1 Like
8

I doubt any of these will create any significant hurdles. The team has done a very good job making sure everything is backward compatible and if there is some new feature that requires a bit of refactoring, you can continue to use the current compilers without upgrading.

2 Likes
9

A couple of questions and a suggestion.

  1. Is there some thought that some of the community developed collection libraries aren’t of a production/optimized quality. I’ve had a good bit of success with Mops • Motoko Package Manager and Mops • Motoko Package Manager.

  2. Time is interesting because I use nat a lot of places because everything is in the future for my protocols, but a historical system would need int and negatives. I’m not sure the best way to handle this and would love suggestions. Nat seems cleaner and easier to use, but guess Int is more correct.

  3. Suggestion 1: To establish modularity as a norm is suggest not just “Base 2.0”. I’d put systems stuff(Time, Timer, cycles, IC,etc) in a Sys module, the variable types in a “primitives” package, collections in “collections” etc. The sooner we get people thinking in modules the sooner they start to think they could contribute one themselves.

  4. Suggestion 2: Along the lines of 1 I’d suggest avoiding a “not created here” mentality. If the existing, more advanced collections need work or optimization, I’d love to see the motoko team contribute back to the third party libraries to normalize third party contributions. If we do feel like some of those need to migrate into a “base” for developer experience, I’d suggest making a BFD about it. Enshrine the contribution somehow…maybe fork into a sub module? I’m not sure the best practice, but we want to celebrate third party contributions and not make devs feel like their work is being absorbed by the foundation.

4 Likes
10

In addition to exposing the capabilities offered by the system API, we’d like to explore whether there are any additional conveniences we can provide on top. Perhaps a way to filter by timestamp or keyword, etc.

1 Like
11

Thanks for the suggestions Austin! I really like the idea of establishing modularity in base to lower the barrier of entry to community contributions. This will be discussed with the team.

Also to your second suggestion: well said. The logistics are something we’ll have to think through some more. But perhaps we can start by contributing to the Map library you linked above.

1 Like
12

Base Lib 2.0 and is most welcoming. Excited to use data visualizer.