I'm the author of a Wasm on the server side runtime[0] that focuses primarily on rust compiled to Wasm, and this question comes up quite often. Why compile to Wasm if you can compile to native code directly? To add to Radu's answer, here are some of my favourite reasons.
Having an in-between bytecode layer allows you to build application architectures in rust that would not be possible when compiling directly to machine code. Hot reloading is a good example. Having the VM hold onto resources like tcp streams and file descriptors allows you to exchange the business logic without even breaking a tcp connection. Fine-grained sandboxing is another good example. Revoking filesystem access from just parts of your applications or limiting memory/cpu usage for each individual request[1] is something that is just impossible to do correctly without a vm managing it.
A less obvious benefit are the improvements to the developer experience, like compile times. Most of the dependencies (async executor, tcp stack, message passing, ...) are usually already part of the wasm runtime and don't need to be compiled/linked again. The rust compiler also seems to have a better time when it comes to generating .wasm executables instead of native ones. Most rust wasm apps I write compile much faster than equivalent native ones. Just because there is so much less for the compiler to do.
Many wasm runtimes, like lunatic, include an async scheduler and green threads/processes. This means that you get most of the benefits of async rust without needing to actually use async and worry about all the issues that come with it[2].
Thanks for the response. Lunatic seems like a really interesting piece of software. Allowing you to run anything that compiles down to wasm seems like an awesome opportunity for a platform to solve some of the headaches of current serverless setup.
But you can already do this with DLLs or with SOs files. You can keep your network logic for example inside another module (perhaps the host app) and then load the logic that acts on the received data as a dll.
Process separation and IPC natively using a library such as Qt is literally a few hundred lines of code.
But that's sort of moving the goal posts now. Original claim for WASM was that it allows hot reloading. Which is a thing you can do with DLLs just fine.
No, the original claim of Wasm definitely isn't only one side point about development. The original claim of Wasm is that all of these features are packaged in a well thought out whole + the success of this platform (thanks to browsers mostly) is what's so interesting about it.
It is also hard to contain the DLL/SO, every system has different mechanisms to ensure it can not access 'everything'. Wasm, as build for the browser, has it in its DNA.
Could you explain more about how hot reload works? I don't see how you can continue from some arbitrary point in an HTTP request, for example, without having detailed knowledge about how a language stores its state in memory and how the code changed between versions.
Having an in-between bytecode layer allows you to build application architectures in rust that would not be possible when compiling directly to machine code. Hot reloading is a good example. Having the VM hold onto resources like tcp streams and file descriptors allows you to exchange the business logic without even breaking a tcp connection. Fine-grained sandboxing is another good example. Revoking filesystem access from just parts of your applications or limiting memory/cpu usage for each individual request[1] is something that is just impossible to do correctly without a vm managing it.
A less obvious benefit are the improvements to the developer experience, like compile times. Most of the dependencies (async executor, tcp stack, message passing, ...) are usually already part of the wasm runtime and don't need to be compiled/linked again. The rust compiler also seems to have a better time when it comes to generating .wasm executables instead of native ones. Most rust wasm apps I write compile much faster than equivalent native ones. Just because there is so much less for the compiler to do.
Many wasm runtimes, like lunatic, include an async scheduler and green threads/processes. This means that you get most of the benefits of async rust without needing to actually use async and worry about all the issues that come with it[2].
[0]: https://github.com/lunatic-solutions/lunatic
[1]: https://www.youtube.com/watch?v=8gwSU3oaMV8&list=PLdo4fOcmZ0...
[2]: https://eta.st/2021/03/08/async-rust-2.html