Motoko wishlist - Motoko Developer Working Group

Developers
1

Hi :wave: Here’s the wishlist/suggestions that I brought to today’s Motoko Developer Working group.

1- Different type of types? Maybe having: 1. Types for data structures, 2. Types for interfaces, 3. Type for operatives.

2- More info in the function MSG. We now have Caller, it could be great to know if the call came from a canister, from an http request or from an API call. In case it’s an http request, know the URL and in case it’s an API call, know the IP address.

3- Generally available types. Principal is generally available as a type, but I would love to make Address/AccountID for ex, generally available to use without importing it.

4- Get candid automatically, so there’s no need to have a .did to reference in your code. If I need to code a canister, just being able to create the actor without the IDL?

5- I would love to know, without maintaining my own mapping, which public variables are there in the code. I’m not too savvy on this topic but I think Game Engines use reflection to allow User Interfaces to populate with data available in runtime.

6- Suggestions or security layers to reduce upgrade risks. How do we prevent the lost of data during upgrades, language level. Maybe having more docs on how types design can break your type consistency, or if you set an attribute as optional you have less risks on upgrading errors, etc. It’s not just documentation, but how can we make less possible for devs to lose data. I see that for now it’s super risky to have an app on the IC. It feels risky and it’s scary…but it should be even safer and less riskier than web2. For Rust I guess it’s ok but Motoko is looking to be a “for everyone” language, right?

7- I think we need better and simpler ways to orchestrate and interop between canisters…If I want to have a microservices architecture with a lot of services for just one app, things get messy really quickly. I think there should be better ways to tie canisters.

8- Being able to have extensible actors. This is just for having the ability to create multiple files with public functions. The idea is to be able to modularized my public functions, the developer doesn’t necessarily want them in the same file.

9- It’s a bit problematic that I cannot manipulate and/or declare my stable data structures outside my actor file, that could be fixed with the extensible actors thing that I mentioned previously.

10- I would love to have “prefunctions”. E.g. Have my authorization module to be executed before certain functions. It’s not only allowing me to have a function that always executes before every function but also that lets me choose what to execute when each function is called. That could fixed the repetition of authorization code, canisterIDVsPrincipalID validation, in a future, maybe IP address validation, etc.

11- If the code itself could show an approximate of cycle consumption and/or time spent for a function, that could be awesome. Not sure if possible but this is my Christmas list so yep…that would be great.

@matthewhammer

5 Likes
2

I will add one too.
Linking or interfacing with foreign libraries, particularly those written in C, Rust, or similar low-level languages. Most successful high-level languages always bring powerful C libraries - JS, Python, Perl, PHP.

4 Likes
3

That’s a great list, I’d especially like to see more tooling to handle persistence cause as you said managing a live dApp with Motoko feels scary atm.

There are a couple more things I’d add:

  1. Native interoperability with other WASM supported languages: Rust, C++, Go, etc… It would instantly give Motoko access to hundreds of libraries and effectively make it the Python of the IC.

  2. Variables as shared types, the only reason I’ve found for why variables aren’t shared is users of the API would expect the value to be replicated automatically, that doesn’t really make sense as it isn’t the default behaviour in other environments, converting variables to constant types only adds friction.

  3. Something like a toData method which automatically strips all functions from objects and makes them shareable.

2 Likes
4

Thanks for posting this list @CapuzR , and for presenting it in the working group session.

@Zane and @infu, thanks for your additional items.

I want to call out this one in particular:

Thanks for voicing your support.

FWIW, we’ve been discussing this internally over the last couple of days (and it’s been an ever-present topic in the background for a long time).

Technically, this may be hard to achieve, especially without Wasm having widespread support for the Component Model, and us having a fragile Wasm linking story as it is (@ggreif and @claudio know those details more than myself, at present).

Yet, I personally advocate some significant team push in this direction, even if the first attempts at some kind of FFI system may be less than user friendly, perhaps.

Nevertheless, I believe that it’s important to push in this direction so that Motoko can feel more open to extension by its users, with libraries and languages outside of Motoko itself, and in particular, Rust.

A common situation is having to write query methods in Rust and use them from Motoko to supplement Motoko’s lack of library ecosystem. An FFI system would make this more efficient in terms of time and cycles, by permitting that extra Rust-based functionality to be a part of the Motoko canister’s Wasm module, directly. But doing that also poses all of the challenges of linking Wasm, etc.

PS: If you haven’t already done so, consider up-voting the corresponding topic on the DX feedback board.

3 Likes
5

In a perfect world (pun intended) a collection of modules with a pre-defined interface (these are actually called worlds in WASI parlance) could be uploaded onto the IC and shared with some principal. Then other canisters could simply refer to that principal to be automatically linked (e.g. with a Unicode library or a language interpreter) and thus become runnable.

Clearly such a scheme would subsume OP’s desire of cross-language interoperability and much more. It would also relax the many canister size concerns as shared modules won’t contribute to the installed canister footprint.

1 Like
6

Multi-language linking is a much harder problem than apparent at first. You need:

  1. A common ABI for calling conventions and passing data between multiple languages. That essentially is what the interface types of the component model provide (which are very similar to Candid), though at a fairly high-level of abstraction that involves wrapper functions and de/serialisation for any non-numeric data type.

  2. A common linking model. That is also something that the component model defines, but in a relatively specialised way tailored to a rather different scenario and with quite a bit of complexity that would probably not be needed on the IC.

  3. Policies for accessing memory, sharing memory, managing memory, ownership and lifetimes of shared data, etc across language boundaries. That intentionally is not something that the component model offers, since it is designed as a more high-level, shared-nothing approach. Hence it does not cover many of the common FFI use cases. I am not aware of any practical proposal to solve this problem for Wasm, it’s a hard problem.

Even if we had solutions to all this, every language implementation would have to agree on them and implement them. For most, that likely requires substantial changes to the innards of their compilers. Hence, this is not something Dfinity can solve by themselves, it can only be solved by the Wasm community at large.