#ask How should we improve Motoko?

Hey everyone,

We are talking with the Motoko team about their future roadmap. What are your top suggestions for the language?

Just to give you a starting point here are some of the topics we are discussing (you don’t have to limit yourself to those):

  • Syntax. Making language syntax more expressive and pleasant to code. Like supporting some functional programming primitives or making it easier to serialize data structures.
  • Libs. Improve the library ecosystem by improving packaging tools (vessel) or enable libraries written in Rust.
  • Testing. Better unit/integration testing support. Code linters.
  • Motoko playground improvements to make it a more serious development tool.
  • Tools. Better formatters. Better IDE support. REPL for Motoko.
  • Debugging using the local replica.
  • IC support. Improving support for core IC features, like the support for BTC / ECDSA / extended memory / certified queries.
  • Performance / execution efficiency improvements, like GC optimizations. Getting closer to Rust in performance.

Please, let me know what you think!

Best regards,
Mikhail Turilin
Product Manager
DFINITY foundation

9 Likes

VSCode plugin that automagically handles imports!

9 Likes

The biggest one for me is a plan for stable memory moving forward (see here). For example, should ExperimentalStableMemory be kept as is (and graduated from being “experimental” to “production-ready”)? Can we have stable data structures like the ones developed in Rust for the BTC integration, where they transparently store data in stable memory directly (without going through stable variables)?

And a couple random ones:

  • spread syntax to construct a record from an existing record
  • type inference in generic functions to avoid having to specify Trie.mapFilter<..., ..., ...> every time I call it, e.g.
  • language server doesn’t check files if they aren’t imported from the main Motoko file
  • add IC management canister interface as a Motoko type in the stdlib
  • operator overloading for classes (as a side note, how is equality even defined for records and arrays? the docs are not too clear)
6 Likes

I dont think that performance and testing arent as important for the immediate future.
If someone needs full functionality, performance and other advanced features they will use Rust.
Motoko should be easy to use with tooling and debugging. That way new people can more easily onboard and have more people be able to build up library support for the ecosystem

The being said, my personal pain points are:

  • Better non-canister/dfx (library code) support for things like VSCode Language Server and building. Currently I use a dummy canister for dfx support and also use wasmtime/vessel for building
  • Something like ? operator rust has to avoid tedious switch statements everywhere to propagate errors/nulls. Introducing ? - Rust By Example
  • VSCode debugging
  • Numbers a annoying to constantly change between Nat8,16,32,64,Nat. The only way I can find to convert between 2, like 8-16, is to convert to Nat, then down to another, like Nat8 → Nat → Nat16
  • Better library/vessel package management support
4 Likes
  • a sort of Prettier code formatter to format the code automatically. To make collaboration (review) easier and code looks always good

  • agree on a “better library/vessel package manager”. For the best and the worst, something as dead simple as npm i that_package

2 Likes

There is MOPS https://mops.one package manager for Motoko. With mops you can install package as simple as mops i that_package :slight_smile:

4 Likes

Cool. It’s open source?

Yes - GitHub - ZenVoich/mops: Package manager for the Motoko programming language

3 Likes

Cool :+1:

Starred and you may have received a PR that adds the repo url on your dapp :wink:

1 Like

Great! I’ll take a look in a couple of days

2 Likes

Isn’t this already possible by using do ? blocks? But yeah I agree there could be a bit more syntactic sugar around optionals, something like Optional1?(#err1).Optional2?(#err2).Optional3?(#err3).value would help a lot.

Rust’s trait system to write polymorphic code/do object composition and macros/reflection would also be nice to have.

2 Likes

I think Motoko could benefit of more detailed error handling.

But the biggest improvement would be a higher level of IC support. Motoko its the native language of the IC and I feel it should not be limited to constant workarounds to access core IC features by us devs.

2 Likes

I feel it should not be limited to constant workarounds to access core IC features by us devs.

I agree. It took months for inspect_message to be available on Motoko, as one example. All NNS canisters are written in Rust, so in that sense Motoko doesn’t feel like a first-class citizen in terms of feature and library support. Another example is the StableBTreeMap data structure that was developed for the BTC integration, and is available only in Rust.

5 Likes

I really like the idea, that you want to listen to the Community, big respect from myself <3.

idea: Can we get more Tutorials for beginners?, maybe something like, “From 0 To Hero” so that everyone can try and learning.

Thank you very much.

4 Likes

First off, I agree with pretty much everything you already have up there.

In addition to this, it would be really neat to be able to mock imported libraries and actor APIs in order to actually unit test, instead of testing much more than just the logic of a particular function or worse, requiring an integration test when the ability to mock an inter-canister call would suffice and make developer’s lives so much simpler.

We currently have methods for accessing canister RTS statistics such as Prim.rts_heap_size(), but from my understanding some of these stats are an approximation. Specifically, that the rts_heap_size measurement becomes less accurate and over-estimates the heap size if the developer has a data structure that takes advantage of sharing (multiple pointers or indices to the same data).

I don’t know what type of effort or lift this would take, but it would be great to see the team explore how accurate a Prim.rts_heap_size() V2 could get while maintaining low cycle cost efficiencies, as well as overall encapsulating this Prim.rts_xxx tooling into a higher level, more stable developer facing library that would allow a canister be able to efficiently inspect and receive real time stats on its utilization.

1 Like
  • easy in-line / lambda functions
  • library for asymmetric encryption
3 Likes

Hey all…quick survey here…what is your most requested syntactic sugar for Motko?

What would that look like?

Template strings / string interpolation would be really nice

3 Likes

How about a way to utilize environment variables?

Currently if I want to make an inter-canister call I have to include the canister’s uuid, which is a very manual process and not sustainable from a devops perspective.

let admin = actor “rrkah-fqaaa-aaaaa-aaaaq-cai”: AdminActor;

It would be great if I could load that canister id from my computer’s environment rather than having to swap that every time I deploy to mainnet or my local replica. If this is possible now or I’m doing this incorrectly please let me know!

2 Likes

I’m thinking like the following:

(x : Nat) : Nat => x +1