As part of Azle’s next release, I’m trying to compare the features of the Rust CDK, Motoko, and Azle. Here’s the documentation I have so far: GitHub - demergent-labs/azle at 431_feature_parity_documentation
I’m at a loss for understanding if some lower-level features are exposed by Motoko. Can someone help me out here? I’ve linked to the main section of missing feature documentation above, the question marks indicate what I don’t know. I’ll list them here as well.
My main question is if the following features from the Rust CDK are exposed in Motoko:
- arg data
- arg data raw
- arg data size
- notify
- notify raw
- notify with payment 128 (if notify is supported this is probably supported with normal cycles addition to the next call)
- reject
- reject code
- reject message
- reply
- reply raw
- result
1 Like
By design, none of these are exposed directly in Motoko but the System API equivalents are used in the implementations of Motoko’s higher-level abstractions.
1-3 is shared function argument binding.
4-6 is calling a Candid oneway function with or with cycles.
7-9 is exit via uncaught throw from a shared function
10-11 is exit via return (explicit or implicit) from a shared function.
12 is shared function call result handling, I guess, which is rolled into Motoko’s await, continuing on success or implicitly throwing an error on failure.
It looks like notify lets you call a non-oneway function as oneway, whether declared oneway or not in Candid. Motoko does not support this directly (but I think it can be achieved via a cast).
Rust lets you bypass Candid. Motoko does not, except for supporting raw calls, sending an receiving raw binary data (possibly non-Candid).
Rusts lets you declare non-Candid function/entrypoints. Motoko does not.
4 Likes
An enterprising Motoko dev could code up an example of each and it would make a great addition to some documentation/tutorials somewhere. It would be a really great way to understand how the IC works.
1 Like