Is Motoko like Rust?

In Hans’ Hackin the internet videos he mentioned he had been using a lot of Rust because it compiles to web assembly and I’ve always just been in the standard js framework world of vue with html, css, js, and aws backend service. I’m trying to connect the dots of all the different languages.

After some research my understanding is that js frameworks are great for most cases and the simplest to use. They provide js to the browser and the browsers can read and run that js. Maybe they compile it to something else and learn to improve speed. Cons are its slow and maybe some kind of less security issue??

Other languages like Go, C++, and Rust all get compiled to “machine code” which is web assembly i believe and browsers can run that which is faster and more secure but it is harder to write. Now I’m a bit grey on the part where it all gets connected to html and css. It seams as though in the code you specify the functions that can be called publicly from the html. And the “dom” is like <input @keyup="myFunc" /> and myFunc could be a public function from the backend code or even js.

So is my understanding sort of on the right track? Sounds like c++ is very hard, Rust is better and Go idk but is Motoko essentially like these? So what was Hans referring to when he said he was writing a lot of Rust. Would I use Rust and Motoko together or is Motoko a “better” rust? Perhaps just written to be able to run on the IC and access Canisters easier. And canisters are like serverless functions that run in the IC and get sent quickly to client. Which is possibly different because doesnt run in browser??

I’m best at vue and I’m not sure I’ve quite yet put together what is supplementary for what because vue is frontend but if I were to do things to the best practice that you guys and everybody recommend for a pwa or app downloaded straight onto computer and run maybe (which im not sure if is better and may allow for less limitations that the browser may have and is more secure) I’d like it to be as best practice as I can with nice frontend but not necessarily need 8 rocket scientists to figure it out although I’m not in a rush and willing to learn and spend time on this.

2 Likes

You might find one of Lin’s talks good for a primer on WebAssembly: https://forum.dfinity.org/t/webassembly-resource-links/62/3

Rust and Motoko can both compile to WebAssembly and run on the Internet Computer, so you can choose either (even both) this is what Hans was referring to. But it’s worth keeping in mind that Motoko has features which make writing for the Internet Computer easier, including hiding some complexity so you can concentrate on other things.

Javascript is what you want for the front end, as you’re already used to, and you can call your WebAssembly canisters’ public methods from your javascript code, some of the tutorials you’ve looked at show this in action.

2 Likes

Ok and so would I still use any js for more temporary/ basic local functions and local state type things and matoko more for the crud backend operations that are for permanent universal storage. Also so are the canistors essentially “serverless functions” so every function call needs to send and receive a call and so some things would be best used with simple js functions because they wouldn’t need sent out and brought back

1 Like

It sounds like Go is sort of a simplified while Rust has a bit more ability, though it may take slightly longer to code, but has some benefits like speed. Also I see a lot of talk about memory usage, concurrency, and other stuff. So Motoko is built with Rust so is it basically the same as Rust just with extra stuff for working with IC. Or is it built with Rust but built to run differently and may have differences in some of these aspects like speed, memory, simplicity, security, etc.

motoko isn’t build with rust, they are two completly different languages. i don’t know how far away we are from a GO sdk for the internet computer, i’d suggest you’d either learn rust or motoko if you want to get started in the near future and make use of the tools that are already available. motoko is the language for the internet computer and has some built in support for programming in this new paradigm (like easy inter canister calls). but of course you can use other languages like rust that compile down to wasm, it’s always a question of what you want to do.

3 Likes

The more I read the more I am interested and more questions I have haha. Sorry to keep asking so much but hopefully helping others with same questions. So js is run on the clients browser. So is wasm which Rust, Go, and Matoko compile to and its faster. Alternatively you can run a serverless function that sends a request to a function that runs in “the cloud”. Now do serverless functions still perform best on wasm or do those machines run other stuff better. Furthermore is the IC running serverless functions with your canistor or are they sending all the functions in wasm to the client to run on clients machine. I’m sure both have their pros and cons as far as security and speed but this is what I’m really curious about rn

1 Like

correct!

what is a serverless function for you?

Currently I think of it as an aws lambda function. And Idk it in detail but it sounds like it’s “the future” of course different random things get hyped up and there are arguments for different things like idk if youre offline then you wouldnt be able to call remote functions and it would be worse for that. It seams like the purpose is that the code gets ran not on your phone but somewhere else that can’t be messed with if someone is running a calculation and updating the database maybe some hacker somehow skips the function and updates the database with something else and is just idk faster maybe despite having to send and receive data across a network. I’m not on expert on the pros on cons of it and need to do more research but I just want to use like the safest best practice I can which it may be case by case as to which would be best for what but was curious as to where this fits in with Motoko since Idk i know the whole database structure is different in how it all connects and I’ve watched a bunch of videos just havent connected all the dots in my brain yet

I think it might be worth you diving in and building some simple apps with what you know actually, this might consolidate things for you and you can experiment from there.

A bit of direction if you want it: Start with Motoko for the backend, running on a local replica via dfx, and a javascript frontend that populates the provided app div, the same way the React examples do. Once you’ve built a few things it’ll really start to click.

Your Motoko knowledge will actually give you a stepping stone to Rust should you decide to then try that, since they have a few things in common, so this would be time well spent.

3 Likes

Yeah you’re prob right! I made the hello world one and then was having issues with some of the others and was told may just be because some changes are occurring and what not so I just set it aside for nowand was gonna wait a few weeks for it to mature a bit more before starting again and started trying to understand more about it in the meantime

1 Like

That’s a fair point! The new version should be out this week or early next, then you can really get your teeth into things a bit more!

3 Likes

It seams like Go is generally more used currently than Rust but I am getting a preference sort-of for Rust because I don’t mind being clearer with things and has a bit more speed from what I read. Which means I’ll probably enjoy Motoko too. I am going to try and do some Rust practice this week and then get into Motoko. Do you know though how Motoko compares to Rust in the speed category? I imagine that they’re pretty similar but idk

They’ll both be compiling to WebAssembly anyway, which is what’s running on the platform underneath, so I’d more consider which one you’re most comfortable writing in. By all means try them both and see which one appeals to you!

Ok I may just ask a bunch of questions cause I’m curious but don’t feel obligated to answer cause I don’t want to take your time. There must be some difference because there are speed differences when you look up the term “benchmarking” even though they all compile to wasm. But so wasm or js runs in the browser hence its use case. Differently in the backend things arent run in the browser right but rather “runtimes” like python and node.js which are not restricted to wasm or js, right? Im not sure if backend runtimes even use wasm or what they do and if theyre faster at running programs in the runtime rather than the browser. Either way Go and Rust for example and any language show speed differences according to this for example https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-go.html

Unless you really want to write an application where speed is critical, i wouldn’t care too much about it as you probably won’t notice any difference in most applications anyways. Another thing is that i’m not sure if there even is a difference in speed between the languages after you compile your programm to wasm and execute it. That said, follow Ori’s advice and try out both languages to decide which one appeals more to you. My opinion:

  • interested in focusing to write apps for the IC -> learn Motoko

  • interested in learning a general purpose language that can also be used on the IC -> Learn Rust or Go (I’d prefer Rust as we know there will be support for dfinity soon, whereas i heard nothing about go so far and you migh need to wait a long time to actually have a toolchain)

3 Likes

thanks for those answers!. Yeah I don’t know why it would ever make sense to run stuff on the fly. Totally makes more sense to compile it in advance for everyone and every machine. And in which case idk why anyone would care about compilation time because its a one time thing except while you’re developing but like its pretty rapid right so who cares if its 0.5 seconds or 1 second or even 10 seconds.

I am particular interested in speed because I am interested in using large datasets like cryptocurrency related info and running some kind of number crunching type stuff on big data. So thats where I believe the small things in how I learn to build can turn into significantly noticeable results. I mean obviously I could run through an insane amount of data whatever I end up doing but if something can run faster than any alternative than could make a minute long wait be 8 seconds or something and thats a big deal.

“Machine code” is always just 0’s and 1’s and is the end result for any computer running on browser or server right. And does a given set of 0’s and 1’s read to perform the same task on every browser or server. Or does python runtime have its own way of reading them and rust runtime a different. I’m guessing sending the entire machine code precompiled to 0’s and 1’s is too big and so it compiles to a smaller version (webAssembly)to be sent over network and the browser can translate the smaller file over the network into the actual 0’s and 1’s to be used.

But on the server you don’t need to send the function across any network anywhere so maybe that can skip the (wasm) interpreting part and just be translated into final machine code to live on the server on save. And on server we dont care how big the runtime or anything is because its not getting sent down to each computer so it could be huge and built to run functions really fast. Cause “machine code” can be different based on the machine right. Just cause all the browsers adopted their standard way of machine code doesnt mean its the best we can get right and servers cant use their own machine code style and handler right?

1 Like

Apologies I might rewrite that later, indeed some term mangling in there.

Regarding on the fly or compiled, these languages are all really tools for different jobs, with different trade-offs and features, so you can chose the one you need. If you take a look at Lin’s talk I linked to the other day she explains the benefits of an intermediate compile target. I used the term interpreted a bit loosely there, there’s a whole lot of what’s called just in time and ahead of time compiling going on too.

1 Like

Here you go! Version 0.6.0 should run with the latest docs for you, if you want to try some of the tutorials again: It's finally HERE - V0.6.0 is now available for download!

3 Likes

Yep I just randomly checked actually yesterday and noticed and was in fact able to successfully do tutorials and now going to try and tweak them and play around. Thanks!

2 Likes