We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Progress of Rust and WASM in 2019

00:00

Formal Metadata

Title
Progress of Rust and WASM in 2019
Subtitle
The year in review
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
There was a huge progress in Rust tools for WebAssembly in the last year. Let's review some of the most noticeable changes. The talk is mostly about wasm-bindgen.
Computer virusDescriptive statisticsReading (process)WordComputer animation
CodeDescriptive statisticsNumberComputer animation
BuildingModule (mathematics)Computer animation
Semiconductor memoryMemory managementPointer (computer programming)CASE <Informatik>Endliche ModelltheorieHermite polynomialsMereologyNeuroinformatikProgram slicingRaw image formatComputer animation
View (database)Library (computing)Endliche ModelltheorieShape (magazine)Expert systemModule (mathematics)Active contour modelView (database)Functional (mathematics)Semiconductor memoryBitNeuroinformatikPointer (computer programming)Contrast (vision)Scripting languageValue-added networkState of matterAreaComputer animation
SummierbarkeitLibrary (computing)Functional (mathematics)Memory managementCASE <Informatik>Proper mapWrapper (data mining)
Library (computing)Point (geometry)Line (geometry)ResultantState diagramComputer animation
BuildingClosed setMathematicsLibrary (computing)Web 2.0State diagramScripting languageComputer animation
Square numberFunctional (mathematics)Correspondence (mathematics)Different (Kate Ryan album)Scripting languageMereologyAdditionWeb 2.0State diagram
Library (computing)Thread (computing)SynchronizationWeb crawlerLibrary (computing)VolumenvisualisierungBitArithmetic meanFamilyWritingLimit (category theory)AdditionFunctional (mathematics)Thread (computing)NumberWeb 2.0State diagramWeb browserCompilation albumComputer animation
Functional (mathematics)Line (geometry)
ResultantLine (geometry)Reading (process)Message passingFunctional (mathematics)Endliche Modelltheorie
Demoscene
MultiplicationType theoryInterface (computing)SynchronizationRun time (program lifecycle phase)Library (computing)String (computer science)Pointer (computer programming)NumberLibrary (computing)Web browserReading (process)Multiplication signInformationDifferent (Kate Ryan album)Extension (kinesiology)Drop (liquid)Similarity (geometry)Video gameTerm (mathematics)Scripting languageBuildingType theoryInterface (computing)Latent heatKeyboard shortcutNichtkommutative Jordan-AlgebraMoment (mathematics)Run time (program lifecycle phase)Software bugSemiconductor memoryComputer animation
Link (knot theory)Mechanism designMixed realityKey (cryptography)BuildingMultiplication signNeuroinformatikCoefficient of determinationInterpreter (computing)
FacebookPoint cloudOpen source
Transcript: English(auto-generated)
Hello. Happy Fozdam. My name is Ilya Baryshnikov. Okay. My name is Ilya Baryshnikov. A few words about me. I'm a curator of Avi.
I work at Align Technology, and I use Rust and WebAssembly at work. If you go and check Avi, you can find a 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 a talk mostly about Wasn't Bunch. 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.
Here's 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 slice from raw parts and so on. So just, we have to do it on our own using plain Rust C.
And it's a way to compile. We use CDI-lib, maybe. It's just a dynamical library when using the target. And when calling from JavaScript, it looks like this. So at first, we need to fetch and instantiate our WebAssembly module.
Then we have to access our experts. Then allocate in 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 view 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 Wasm-Byndjian. Using the CDI lib again, just adding the dependency.
And Wasm-Byndjian 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 camel 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 Wasm-Byndjian. It just does a lot of work for us. Then what about std web? There is really, there was a crate,
just created before Wasm-Byndjian, and a lot of libraries written using std web. And after Wasm-Byndjian was created and became more mainstream, people started to suggest, like, let's rewrite this library from std web to Wasm-Byndjian.
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 Wasm-Byndjian itself.
One of the most noticeable change was JS snippets. As JavaScript is a modern assembly, we can have inline JavaScript in our Rust. Seriously, I'm not kidding, it's just...
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 Wasm-Byndjian, which helped to build a part of std web on top of Wasm-Byndjian. And luckily, 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 Rust for web,
just 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, Chrono, or recently there was a release of Winit which got WebAssembly support using both std web or Wasm-Byndjian. You can choose which one. And Rand improved some, fixed some issues.
And a lot of other crates. I guess JFixRS got WebAssembly support this year. So about Rayon, there was a nice addition which allows you to handle threads spawning 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 Async8 landed in unstable Rust.
And when it comes to WebAssembly, we have to connect JavaScript promises with Rust features. And the create Wasm-Byndjian features does this for us. So it provides interoperability, and it is a distant executor.
So it's a 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 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 Wasm-Byndjian start,
everything would run, and all the Async stuff. So you can just have Async await in Wasm-Byndjian and use it on stable, and everything works. And 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-wasi 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-wasi creates a package which you can run in standalone runtime. For example, in Wasm time or any other. So it also supports building and running. So you can cargo-wasi run or something like this. And it's really nice to,
also there was, well, the things before, they are kind of more related to Rust or to Interop. But this one is an extension of a 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 bindgen and a number of other tools. And it is 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 memory layout.
And multi-value is a prerequisite for it. And so the support of multi-value was added to Wasm bindgen and read more in this article. And to summarize, we got better interoperability,
more libraries supporting compiling to WebAssembly. We can now use async-await with Rust in a browser. And we have more runtimes and better support with cargo-wise 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. Yeah, questions?
Okay. You mentioned that Wasm bindgen features comes with its own executor. Can you clarify if you can mix JavaScript-based features with Rust features? Okay, the question is that Wasm bindgen 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 tick. 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 wait, I think, atomic. Wait, I think it's a proposal. There is also a polyfill. So just in short, yes, we can use both of them
and interoperate. Next. Thank you very much. Thanks.