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

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