Introduction to Rust and WebAssembly
This article is part of a serie: Rust and WebAssembly
- Introduction to Rust and WebAssembly
I’ll start by presenting each of these two technologies and which problems they are trying to solve. Then, I’ll explain what are the advantages of a Rust-powered Wasm module, and why it can be useful. Finally, I’ll provide links to interesting documentation.
From asm.js to WebAssembly
WebAssembly has taken one step further, by defining an instruction set from scratch. A VM which can execute this instruction set is implemented in the browser. This system has been designed with modern knowledge, and performance and security in mind. Thanks to LLVM, many compiled language can be compiled for this platform, including Rust.
WebAssembly without web-browsers: WASI
The execution engine can be extracted and run non-web applications (remember, any language can be compiled to Wasm, instead of x86_64-linux-gnu). In this case, Wasm uses an interface, WASI (WebAssembly System Interface), to talk to the kernel and execute system calls, in order to read files, use the network, or anything else.
As a comparison, WASI offers similar features as a standard VM or Docker. And this is a big deal, as Docker’s creator puts it:
If Wasm+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. WebAssembly on the server is the future of computing. A standardized system interface was the missing link. Let’s hope WASI is up to the task!
A great future
You’ll probably hear about it again in the future.
Rust is a (not so) new language initially designed by Mozilla, which has been gaining a lot of momentum recently. It shares many similarities with C/C++, but with a focus on safety.
In particular, it offers strong guarantees regarding memory safety: NULL pointers simply does not exist, and non existing data are checked and protected at compile time. Rust has the concepts of ownership and lifetime, and its borrow-checker ensures that a piece of data either has only one owner, either is read only. It is also responsible for allocating and deallocating memory. This is all done at compile time, which allows Rust to behave in a predictable way, without a garbage collector (which means no performance hit).
Additionally, Rust has many high level features such as arrays or operator overloading.
Rust features fully prevent many kinds of issues which exist in C: dereferencing NULL pointers, data races, double free and read after free, buffer overflows, etc.
A language empowering everyone to build reliable and efficient software.
This language is promising for applications which need performance and safety (games, image/video/sound processing, etc). It could also be a good alternative to C for embedded systems and critical software.
In the aerospace industry (and others in which software critical is used), most of the code is written in C (for its predictable performances and large history) and Ada is used for the most critical parts.
If Rust’s performance proves to be comparable to C’s, and its safety to Ada’s, it could become a good alternative to these two languages.
Although some features are not fully stable (notably async), most of the language is quite mature. There are already many projects using Rust, for example Mozilla’s Servo.
To ensure that Rust is safe, it needs to be validated, like C and Ada are. This is the goal of the Sealed Rust project by Ferrous Systems. Their plan is to first specify the Rust Language, and then validate a Rust Compiler. Although I would love it, I don’t expect to see Rust in critical embedded systems anytime soon.
Rust on Wasm
I wanted to learn Rust for some time, because I think it could make me a better C developer, and because I think this languages has interesting features to overcome C’s shortcomings.
Wasm looks very attractive, and the prospect of being able to execute any language in the browser is very exciting.
Executing Rust in the browser has many advantages.
First, sharing code between the front end and the back end would save many people a lot of time. This is true for applications which share heavy client and server, but it is also the case for games and complex business applications.
Recruitment could be made easier as well. Instead of needing to recruit both a front end and a back end developers, only on Rust developer would be needed. This could streamline development.
Finally, performances are improved, which is great for games. Being able to run more ambitious games in the browser could save time when trying to make those games cross-platform.
Starting from the final choice (using Wasm and Rust) to get to the requirements (finding a project to work on), is in most cases stupid. Actually, stupid only if the goal is to answer a business need. In such case, one should start from the requirements and find the best technical solution to answer those needs. But in my case, my requirement is actually to learn, have fun, and use Wasm and Rust.
So, to play with Wasm and learn Rust, I have started a project: implementing the game of (French) tarot1. It might probably never be finished, but I will at least gain some experience with Rust. When I finish, or get fed up with this project, I’ll try to work on something more ambitious or low level (maybe a rocket guidance software).
While reading documentation and tutorials, I found a game made with Rust and Wasm: Pont. The code is actually quite short and more readable than it seems at first sight.
If you want to get started too, you should start here. Note: the setup is a bit complex, I’ll try to write a article with a hello world. Also, the docs are not obvious, but npm is not needed, you can skip it.