 Hello. Happy FOSDOM. My name is Ilya Baryshnikov and my name is Ilya Baryshnikov. A few words about me. I am curator of AV. I work at Align Technology and I use Rust and WebAssembly at work. And if you go and check AV, you can find the number of crates, like with the description and so on. If you know a nice crate and it's not presented there, you can just leave an issue or a kind of a suggestion. It would be very useful. Ah, so it would be mostly about one bungeon. So what is it and why is it useful? Why do we need it? Actually, we can compile Rust to WebAssembly just using plain Rust C or Cargo build. And here is an example of building WebAssembly module just using plain Rust C. But in this case, we have to do all the memory management on our own. Like here, we have at first to allocate the memory and send the pointer back to JavaScript. Then we have to set the memory from JavaScript because JavaScript and WebAssembly have different memories. We have to copy data from JavaScript memory to WebAssembly memory. And then we call our computation where we construct the slides from our parts and so on. So we have to do it on our own using plain Rust C. And it's a way to compile. We use CDI lib. It's just a dynamical library then using a target. And when calling from JavaScript, it looks like this. So at first we need to fashion instantiate our WebAssembly module. Then we have to access our experts. Then allocating memory. And now we have a pointer. Then we have a view into this memory. And as you can see, we divide each pointer by four because the viewer is offset in 32 array and pointer is in bytes. So we have to do all of this on our own. Then when we set the memory, we basically copy the array from JavaScript memory to WebAssembly memory. And then finally we can do our computation. And the function names, they are all in a snake case like in Rust. We are not used to this in JavaScript, so it looks a bit strange. Then we can do the same again in wasn't mined in using CDI lib again, just waiting for the dependency. And wasn't mined in does all of this for us. It just manages, takes the memory management and so on and generates JavaScript for us. And we can annotate our functions to have a correct KML case, JavaScript names. Everything looks cool, so it's just our Rust function without any unsafe or extern. But it's unsafe inside, it's just a wrapper. And then from JavaScript we just import it. And like any other JavaScript function, we pass data again like we used to do and receive the results. Well, that's just the point of wasn't mined in. It just does a lot of work for us. Then what about STD Web? There was a crate created before wasn't mined in. A lot of libraries written using STD Web and after wasn't mined in was created and became more mainstream, people started to suggest like let's rewrite this library from STD Web to wasn't mined in. But what if instead we could just build them together and just use both of them without writing anything? And it was a suggestion to do this. It required to make some changes to wasn't mined in itself. One of the most noticeable change was just snippets. As JavaScript is a modern assembly, we can have inline JavaScript in our Rust. Seriously, I'm just kidding. So here we write JavaScript and we annotate it. It's like the corresponding Rust function. We connect them like with JS name and so on. And then we call JavaScript from our Rust. That's it. So it was the addition to wasn't mined in which helped to build a part of STD Web on top of wasn't mined in. And likely the initial support of limited interoperability. So expect not everything would work perfectly, but at least up to a certain point it would work. It was released and I think it's a big deal. Then just another big point like when we are writing for Rust for web, it would be hard to write everything on our own. We have to use libraries. It would be really nice. So when you just grab a library and compile it and everything is fine, it's great. And this year there was a number of libraries which got WebAssembly support or improved. For example, Krono. Recently there was a release of WinIt which got WebAssembly support using both STD Web or wasn't mined and you can choose which one. And Render improved some, fixed some issues. And a lot of other crates I guess JFix RS got WebAssembly support this year. So about Rayon, there was a nice addition which allows you to handle corresponding on your own and you can even use with a bit of luck, you can use Rayon inside of the browser. Then it was a really big feature when Async await landed in unstable Rust. And when it comes to WebAssembly, we have to connect JavaScript promises with Rust features. And the create wasn't binding features does this for us. So it provides interoperability and it is a distant executor. It's an Rust executor built on top of JavaScript promises. And let's check an example. At first we need to define some JavaScript function which will return a promise like this. And then we annotate our function the first line. It means that this function will run when we just initialize the model. So it's just like a main. And then we can get the promise from JavaScript when calling delayed answer. And just future can convert promise to future. So we can convert the promise to future and then await on it, resolving it to result. And after this we can just log the message. And from JavaScript side it looks like this. We just called init and what was written in wasbygen start. Everything would run and all the things stuff. So you can just have async await in wasbygen and use it on stable and everything works. So it's really cool. Then there were a lot of talks about WebAssembly going outside of the browser. And we do have a number of runtimes supporting WebAssembly. So it's not only browser but any arbitrary just runtime which can run it. And cargo-wise is kind of similar to wasm pack. So wasm pack creates a package for you like npm package or just a package which you can run with JavaScript. And cargo-wise creates a package which you can run in standalone runtime. For example in wasm time or any other. So it also supports like building and running. So you can cargo-wise run or something like this. And it's really nice too. Also there was the things before they are kind of more related trust or to interrupt. But this one is an extension of specification. Multi-value is if I understand it correct. It is not supported by all browsers yet. But well if runtime supports it you can use it. But you still have to build Rust. And here is a great article by Nick Fitzgerald. Where he writes about implementing multi-value in wasm biogen and a number of other tools. And it is a prerequisite for interface types. Because at the moment we can return only numbers from WebAssembly or accept only numbers. And if we want to pass an array for example in the browser we have to copy it to WebAssembly memory and pass the pointers. So interface types would allow us to pass arrays or strings. It's just a definition of a memory layout. And multi-value is a prerequisite for it. So the support of multi-value was added to wasm biogen and read more in this article. And to summarize we got better interability, more libraries supporting compiling to WebAssembly. We can now use I think await with Rust in the browser. And we have more runtimes of better support with cargo wasi and new features like multi-value. And really a lot of bug fixes were made with a number of different tools and crates and so on. Well I guess that's all. And if you want more information I posted all the examples from the talk to GitHub. You can check them and run on your own. Like play with it. Or also the links are here. So that's it. Thanks. Questions? You mentioned that wasm biogen features comes with its own executor. Can you clarify if you can mix JavaScript-based features with Rust features? The question is that wasm biogen features comes with its own executor. So can we mix the JavaScript promises with Rust features? Yes we definitely can. So the executor does poll, poll, poll until the feature is ready. And here the poll is done using callback to JavaScript. So we need just a way to not block, to leave the runtime, to do a next stick. For example if we are not using a feature, if we have to wait. We need a mechanism to wait. So this waiting thing is done using promises. In particularly we have waitisync, atomic. Waitisync is a proposal. There is also a polyfill. So just in short, yes we can use both of them and interpret it. Next? Thanks.