Motoko vs. Rust: Trade-offs now and into the future

[theoman42]

I am in a dilemma, my heart tells me Motoko, but my mind tells me Rust.

It seems that Rust will always remain more computationally efficient (by 2-3x), and this might be the only variable that matters for DAO-controlled, open-source apps.

For any web3 entrepreneur that wants to build the next youtube, tiktok, twitter clone, how can you justify programming in Motoko if it will always remain more expensive to run your services? Any competitor could clone your logic into Rust and undercut you.

Will Motoko, in the future, or even now, possess features that will never be feasible in Rust that would justify Motoko’s usage?

@rossberg

Motoko tries to strike a balance. It’s as high-level as TS, but without the same runtime overhead and most of the other technical disadvantages. As a result, it is not quite as efficient as Rust (I’d expect something like 2-3x, but that may vary widely depending on use case).

@ulan

Here are the results:

• Rust: instructions: 13_761_694, sum: 3_283_500_000
• Motoko: instructions: 92_001_970, sum: 3_283_500_000
• Azle: instructions: 1_341_172_853, sum: 3_283_500_000

[skilesare]

I’d love @rossberg insight here , but I think you ashould take his 2-3x comment in light of one of his other comment

@rossberg

In all scenarios where you want to minimise cycle cost. Because using stable memory is likely many times more expensive. That is (a) due to accessing stable memory itself is much more costly, and (b) because an application or the Motoko runtime has much more severe constraints in organising data layout in stable memory and keeping its format forward/backward-compatible. (The former may improve in future versions of the IC, whereas the latter won’t.)

Think about it as akin to memory vs file system in a conventional computer, where you ask: In what scenario would I want to use memory for data and then have to store it to a file vs just using a file and reading every byte from there all the time?

Rust writes its data to stable structures which will be much more expensive to use than motoko’s new enhanced orthogonal persistence. In addition your upgrades are going to be much more efficient in motoko with eop. Rust will require you to read from and then require to stable memory causing you to repeat that cost. EOP may have some processing cost upon upgrade, and maybe that is going to be 2-3x what your processing cost would be in rust, but likely far less in cycles over all due to stable memory costs.

Someone closer to the compilers and actual memory costs can enlighten this discussion with hard data. I did a bit of searching for benchmarks for system calls, specifically stable memory, reading, right, but couldn’t find much.

A bunch also has to do with what you used to serialize and some people have found some optimization using different libraries, but with Motoko he just put the thing in memory so you’re using base instructions with no serialization or deserialization.

Some info about how stable memory works:

Wasm-native stable memory | Internet Computer

Basically, motoko doesn’t have to deal with all that crap now.

[theoman42]

Thank you for your response Austin. I need to conduct a more granular investigation of my code to determine where cycles are spent. My sense is that more cycles are spent to write data, as betting games aren’t very computationally intensive, which bodes well for the use of Motoko

@skilesare

Rust writes its data to stable structures which will be much more expensive to use than motoko’s new enhanced orthogonal persistence.

It looks like the 2-3x number stands for raw processing, but very curious how much cheaper these writes are with EOP, and how to think about the theoretical limits of future upgrades.

[skilesare]

Yep…now that we have ‘new base’ we should have someone run some numbers for things like ‘writing’, ‘reading’, ‘looping’ through 10, 100, 1000, 10,000, 100,000 entries to a map in 32bit motoko, 64bit motoko, RUST, Azel, etc. Until we have any real numbers then it is mostly speculation.

[kritzcreek]

Facebook is written in PHP, GitHub is Ruby, and Youtube in Python (simplification). All of these are very “slow” language compared to Rust, yet they all became very successful products.

“The next youtube, tiktok, twitter clone” 's costs are all going to be dominated by networking and storage, which is all about designing distributed systems and has little to do with the programming language you do it in.

I’d recommend focusing on developer productivity over squeezing out the last bit of performance (without being wasteful of course).

@theoman42

Will Motoko, in the future, or even now, possess features that will never be feasible in Rust that would justify Motoko’s usage?

A Garbage Collector (which means easy access to cyclic datastructures, first class functions, …)

A strong focus on safety (unbounded Nats/Ints) and ease of backwards compatible canister upgrades.

I’ll also say that for certain computationally intensive tasks Motoko is not going to be a good choice, but you could either delegate that work to a canister written in Rust, or link to a bit of Rust code with the Wasm Component Model (in the future).

[Gwojda]

You should go for rust :

• easy integration, with a lot of library available, well tested. Compiler is super smart, and fast. Motoko’s compiler is slow, and super stupide sometimes ahah
• You can test your code easily with pocket-ic, also in rust. Meaning you dont have to bind all your types

Tradeoff is motoko as some smart native stuff, as it’s closer to dfinity’s in general. async* is smart/usefull for example.

In general : go for rust without any hesitation, easier to find developer, easier to work with, and no real argument to go with motoko right now in my opinion

[senior.joinu]

After coding stuff for IC with Rust for over 5 years and trying to switch to Motoko during last couple of days, here are my thoughts so far.

If you absolutely need performance (computation/storage heavy flow: cryptography, data processing, compression, storage, etc), go with Rust or go even off-chain.

If you want (and know how) to control every single aspect of the execution and squize every last drop of the infrastructure given to you, go with Rust.

But get ready for a lot of code. Rust is a very verbose language - you have to explain a lot to the compiler in exchange for that performance. Also, while Rust’s ecosystem (with absolute majority of crates compiling to wasm without any problem) is orders of magnitude larger than Motoko’s, there is actually very few crates which would help you with IC-related programming. Most of the crates are built by Dfinity, with their own priorities and trade-offs. If your dapp is so unique and demanding that you decided to go with Rust, most probably you would need to implement a lot of low-level stuff by yourself.

For everything else, just stick with Motoko and help it mature. With EOP released recently it is actually easier to code ready-for-battle stuff with it. Stable memory freedom was the only thing that kept me stuck with Rust.

The docs are good, but they could use some simplification. They start with inner-workings and only make sense if you read them completely (a sign that they were written by a deeply technical person). For example, “Objects Classes” section starts with In Motoko, an object encapsulates state, and an object "class" is a package of two entities that share a common name. A package? Two entities? What?
When you read the section carefully and completely you get that the author is trying to say, that there are no “classes” or OOP in the usual meaning and Motoko’s classes are just a sprinkle of sugar on top of objects and functions, but this is not what I want at my first steps with Motoko. I tried laguages already, I know that stuff can be implemented in f-d up ways under-the-hood, this is not useful to me yet. Now I want to know, if this abstraction would allow me to achieve what I want to achieve or I should use something else.
And ideal version of this section for me would be something like: “Classes in Motoko are not real classes like in other OOP languages, but they serve the same purpose. You use classes when you want to be able to create multiple instances of objects of the same shape. For example, here is a human class: … There are no “this” or “self” keywords in Motoko, because of the inner-workings, but here is how you can hack yourself one to make it feel more familiar: …”.

The “canon” code style formatting is beyond good and evil. Don’t know what is my problem with it exactly - it looks and feels too “engineered”. The website’s main Motoko section says “Javascript-like language”, but you won’t find similar formatting preset in prettier or any other opinionated tool. For some reason, while it is completely possible to write code that is almost identical to Typescript, the formating there makes everything to prevent that.

Other than that Motoko feels like freedom after Rust. I have a tiny library in Rust called ic-e8s (helps with fixed decimal point math, like division and multiplication and conversion between decimal points). In Rust it takes 450 loc, while in Motoko it is only 115 loc. It is not as pretty in practice (could use some operator overloading and macros/const generics) but the implementation itself is much more readable.

The project I’m working on right now has a lot of cross-referencing and stuff that is usually super-verbose in Rust (and not quite possible to do in stable memory right now), but here it all just maps from my Typescript prototype almost 1-to-1.

My journey with Motoko has just started. Going to keep you posted if I have something interesting to tell.

[skilesare]

@senior.joinu

Also, while Rust’s ecosystem (with absolute majority of crates compiling to wasm without any problem) is orders of magnitude larger than Motoko’s, there is actually very few crates which would help you with IC-related programming.

I have an unproven axiom that is almost certainly not true for trivial libraries, BUT for all non-trivial libraries: any non-trivial library written for a platform other than the internet computer will eventually, at scale, become a footgun due to the inherent assumption that computation has a user defined termination point(I’m done computing). On the IC you have a consensus defined termination point(you are done computing…cycle limit/checkpoint).

[ggreif]

@theoman42

It seems that Rust will always remain more computationally efficient (by 2-3x), and this might be the only variable that matters for DAO-controlled, open-source apps.

Yes, Motoko was not designed to be a high performance language. But keep in mind that there is a simple switch to activate a binary Wasm optimiser (from which we have seen substantial cycle savings and size reductions). Check the optimize setting.