Why is Rust more used than Motoko

Developers
1

I’ve decided to learn smart contracts development and obviously IC is my go to platform, Motoko seemed like the obvious choice, it has more docs and tutorials, plus it has been made with the IC in mind so it should be a nobrainer, but looking at the ecosystem I get the feeling Motoko isn’t a first class supported language for the IC yet, big dApps (DSCVR) are using Rust and reading the forums I’ve found out some functionalities are currently available only on Rust.

So doubt arose in my mind: “Is Motoko the best choice?”, its way more niche and currently a less marketable skill than Rust and it seems to get all the new features months later, for a tech thats rapidly evolving and in an indutry where being first to market gives a huge bonus, is it really worth it?

What do you guys think?

5 Likes
2

Reasons rust has dominated so far:

  1. Rust has a bunch of existing libraries that can be leveraged as long as you are doing only small bits of work in your contract.
  2. There are more Rust devs.
  3. Until last week Motoko didn’t have call_raw and rust did so certain applications were off the table.
  4. Motoko still doesn’t have inspect_message so it may be more susceptible to DDoS attacks.

My thoughts are that once we build the core libraries for motoko it will be the preferred language and prone to wider adoption than rust.

2 Likes
3

Would you say Motoko makes development significantly easier than Rust?

4

I’m not sure. If you’ve executed the lift to learn rust then I’d imagine rust is pretty powerful. My understanding is that that lift takes a particular kind of person and that pool is much smaller than the group that could approach motoko. I think it is possible to say that motoko is more approachable than rust. Motoko doesn’t require memory management which can be a hard concept to grok when you are also trying to learn a language.

1 Like
5

In addition to the points already mentioned, Rust has no garbage collector so it leaves more space available for your program.

1 Like
6

I expect Motoko to be used to write more business oriented logic, while Rust to use for lower level system operations. Like Python and C. They can mix and match, happily coexist in one dApp if needed.

2 Likes
7

Why would that be the case? Are there benefits in terms of performance when using Rust compared to Motoko?

1 Like
8

Motoko 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.

9

Motoko has a garbage collector while Rust does not. I’m not sure what other performance implications there are. They both compile to wasm bytecode.

1 Like
10

Would be nice in canisters have some concept of message handlers. We can write them in Rust, they can be reusable by different canisters. The purpose will be to intercept messages before (incoming) and after (ongoing) they reach the canister. They can serve auditing, logging, monitoring purposes, provide access permission control, assign additional metadata attributes, like roles. This should be really handled on infrastructure level than business logic level. As canister logic becomes more and more complex this separation will be very important. Just to remember, the real cost of the application is not in development, but in maintenance. TCO

3 Likes
11

Personally I would not worry much about performance differences unless you are doing some expensive loops (to be honest, I did not study how Motoko manages handling of large Candid types, on my bucket list :slight_smile: ) For me is important readability and reusability of my application. Motoko for me is more readable, while Rust has more powerful features. And sure, if there is existing Rust library for it , why to rewrite it in Motoko?

2 Likes