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.
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)
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
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.
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.
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.
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.
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!
