Hello, I am looking to build the best most solid canister software. I am look for an engineer’s/system-ar chitect’s-perspective. I know that the icp-Ledger-canister is in the Rust, so my question is: what are the vantages of each language when writing a canister?
4 Likes
I’ll let others chime in here as well, but some thoughts:
- Rust is a systems engineering language; while it’s very powerful some of its capabilities may not be very useful for developing IC apps
- Rust is about 10 years old at this point so documentation and libraries are more mature than Motoko
- Motoko is purpose built for the Internet Computer; as such it will always feel “native” to IC development
- Both programming languages are strongly typed, statically compiled languages
- Motoko is designed to be readable and familiar to JavaScript
If you already know Rust, then going with Rust makes sense. If you are a JavaScript developer, Motoko might be an easier path. You can find Motoko examples in our dfinity/examples repository.
If you are an expert in an alternative language whose Wasm compatibility is stable for production usage and are interested in a challenge, we are actively looking for teams wanting to implement canister development kits.
13 Likes
@ililic if I were to do async distributed systems type of work handling high message throughput across multiple canisters, would this then be more suited to Rust? I’m comfortable with JavaScript and have been playing around with Motoko, but I wouldn’t call myself particularly married to a single programming language - it’s more about choosing the right tool for the job.
Some of what I’m looking for are:
- Support for async canister communication
- Good serialization/deserialization libraries/feature set
- Reliable heartbeat implementation
- Predictable computation and memory costs (methods/functions and data structures don’t occupy more compute/space under the hood) and efficient garbage collection
- Dfinity Foundation engineers and community have distributed systems support/vision in mind for this language on the IC
2 Likes
- Support for async canister communication
Async inter-canister calls are supported in both Motoko and Rust. There’s no other way to communicate with other canisters.
- Good serialization/deserialization libraries/feature set
Depends what kind of serialization you want. Both the Motoko and Rust CDKs handle Candid serialization over the wire for you under the hood. There’s no need to serialize to disk, since orthogonal persistence means there’s no filesystem accessible by a canister.
If you mean serializing to stable memory (since the IC API is quite low-level and requires the caller pass bytes), then I suppose it’s easier to do that in Rust, although I haven’t done it myself so I’m not sure. But if you have less than 4 GB of data, then you can just use Motoko stable variables, which handles the serialization for you, something that isn’t possible in Rust.
- Reliable heartbeat implementation
Heartbeat is available in both Motoko and Rust as of the latest dfx version.
- Predictable computation and memory costs (methods/functions and data structures don’t occupy more compute/space under the hood) and efficient garbage collection
Rust has no garbage collection whereas Motoko does, so in that sense Rust is probably more predictable in terms of cycle costs. Motoko is continually optimizing its GC algorithm though, so my guess is that this is less of a problem than it may seem? Not sure.
- Dfinity Foundation engineers and community have distributed systems support/vision in mind for this language on the IC
Motoko was specifically designed for the IC. It was a tremendous engineering investment by DFINITY to create a new programming language, and they must have had good reasons to do so. It implements the actor model (i.e. single-threaded entities that asynchronously call other entities), which is the model that canisters run as on the IC. Both Motoko and Rust will be supported for a long time, I believe.
10 Likes
Very detailed answer
Great!
I like Rust more.
rust canister, can not upgrade
storage data:1000MB;
nft_data: Vec<Vec<u8>>,
system info:
Canister status call result for rrkah-fqaaa-aaaaa-aaaaq-cai.
Status: Running
Controllers: iyhc2-feltd-brc6v-ggu73-253xm-rktgs-2uotd-w2gqb-cibyz-ujc2d-uqe rwlgt-iiaaa-aaaaa-aaaaa-cai
Memory allocation: 0
Compute allocation: 0
Freezing threshold: 2_592_000
Memory Size: Nat(1708283378)
Balance: 4_000_000_000_000 Cycles
Module hash: 0x8b6f720b988fe9220a60431f7f6e864472f336e7c2291c13226fe1776ff3a171
Executing: ic-cdk-optimizer -o target/wasm32-unknown-unknown/release/nft-v2.wasm target/wasm32-unknown-unknown/release/nft-v2.wasm
Upgrading code for canister nft-v2, with canister_id rrkah-fqaaa-aaaaa-aaaaq-cai
Error: The Replica returned an error: code 5, message: “Canister rrkah-fqaaa-aaaaa-aaaaq-cai trapped: unreachable”