WebAssembly with Rust
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 8 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/52171 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
RustLatam 20196 / 8
2
4
6
00:00
Open SourceFacebookGerade ZahlRechenschieberCoxeter-GruppeDebuggingRadikal <Mathematik>BildschirmfensterComputeranimationVorlesung/Konferenz
00:33
BildschirmfensterProzess <Informatik>Fächer <Mathematik>ZweiBenutzeroberflächeRadikal <Mathematik>BenutzerbeteiligungCoxeter-GruppePhysikalisches SystemMultiplikationsoperatorFront-End <Software>
01:40
BenutzerbeteiligungAppletSkriptspracheFokalpunktCompilerWeb-DesignerBrowserDifferenteGebäude <Mathematik>ProgrammierumgebungRechenschieberFront-End <Software>BimodulProgrammiererVorlesung/Konferenz
03:14
Kartesische KoordinatenBenutzerbeteiligungLeistung <Physik>Minkowski-MetrikFront-End <Software>Vorlesung/Konferenz
03:56
Formale SpracheDebuggingFront-End <Software>BenutzerbeteiligungBimodulVerzeichnisdienstVorlesung/Konferenz
04:44
BitBenutzerbeteiligungFormale SpracheInterpretiererHalbleiterspeicherp-BlockArray <Informatik>MomentenproblemTabelleMapping <Computergraphik>FlächeninhaltBimodulElektronische PublikationStandardabweichungVirtuelle MaschineKeller <Informatik>ComputersicherheitRechenschieberBinärdatenDickeAppletByte-CodeLaufzeitfehlerDifferenteWort <Informatik>Offene MengeMinkowski-MetrikBrowserGoogolSchlüsselverwaltungMereologieCoxeter-GruppeGewicht <Ausgleichsrechnung>LinearisierungVorlesung/Konferenz
08:02
ProgrammierumgebungHalbleiterspeicherZahlenbereichFamilie <Mathematik>BrowserBimodulComputersicherheitBenutzerbeteiligungGemeinsamer SpeicherSystemprogrammVorlesung/Konferenz
08:44
TypentheorieBenutzerbeteiligungTypentheorieMobiles EndgerätAusnahmebehandlungAppletMicrosoft dot netDatentypGenerator <Informatik>BitParametersystemFunktionalBimodulQuick-SortCodeProgrammierumgebungSchreiben <Datenverarbeitung>ComputeranimationVorlesung/Konferenz
10:38
BenutzerbeteiligungFramework <Informatik>BinärdatenGrundraumMicrosoft dot netSpeicherabzugAppletBildverstehenGewicht <Ausgleichsrechnung>ProgrammierumgebungBimodulMathematikNichtlinearer OperatorComputersicherheitElektronische UnterschriftKeller <Informatik>Elektronische PublikationVirtuelle MaschineMultiplikationsoperatorRechenbuchTypentheorieMetadatenLeistung <Physik>BrowserVorlesung/KonferenzComputeranimation
12:33
DateiformatBenutzerbeteiligungNatürliche ZahlKartesische KoordinatenBitFunktionalBereichsschätzungFormale SpracheDifferenteBrowserSpielkonsolePunktVorlesung/Konferenz
13:57
RauschenPhysikalisches SystemAnalogieschlussCodeFormale SpracheCASE <Informatik>ServerBenutzerbeteiligungTermSchnittmengeSoftwareFunktionalMobiles EndgerätKartesische KoordinatenProzess <Informatik>Offene MengeSoftwaretestVorlesung/KonferenzComputeranimation
15:38
BenutzerbeteiligungAppletSpeicherabzugTypentheorieAssemblerSoftwaretestPeripheres GerätComputersimulationMobiles EndgerätSoftwareLesen <Datenverarbeitung>Gewicht <Ausgleichsrechnung>BrowserVorlesung/Konferenz
16:34
CodeDatentypGenerator <Informatik>Deterministischer ProzessBenutzerbeteiligungAssemblerComputeranimation
17:21
Demo <Programm>ATMFontVersionsverwaltungBenutzerbeteiligungTypentheorieCodeVorlesung/Konferenz
17:50
VersionsverwaltungByte-CodeBrowserStandardabweichungDatentypParametersystemGanze ZahlFunktionalBenutzerbeteiligungDämpfungUnternehmensarchitekturVorlesung/Konferenz
18:54
UnternehmensarchitekturBinärdatenLaufzeitfehlerBenutzerbeteiligungCodeGenerator <Informatik>Klasse <Mathematik>MultiplikationsoperatorBimodulSpielkonsoleBrowserPunktVorlesung/Konferenz
20:06
DatentypProgrammiererKartesische KoordinatenProgrammbibliothekVorlesung/KonferenzComputeranimation
20:40
Interface <Schaltung>WellenlehreBimodulCodeElektronische PublikationCoxeter-GruppeBeweistheorieSchlussregelResultanteMusterspracheDemo <Programm>FeuchteleitungBitRegulärer GraphQuick-SortStichprobenumfangGebäude <Mathematik>BenutzerbeteiligungMultiplikationsoperatorDifferenteComputeranimation
22:21
Web-DesignerProgrammierspracheIntegralFront-End <Software>ProgrammbibliothekMultiplikationsoperatorComputeranimation
22:49
Desintegration <Mathematik>CodeDatenstrukturBitÄquivalenzklassePerspektiveSchnelltasteOrdnung <Mathematik>MultiplikationsoperatorFunktionalMakrobefehlBenutzerbeteiligungBildschirmfensterMAPIntegralLeistung <Physik>Array <Informatik>Regulärer GraphProgrammbibliothekBridge <Kommunikationstechnik>BimodulMetadatenVersionsverwaltungPrimitive <Informatik>SpielkonsoleSoundverarbeitungSelbstrepräsentation
26:02
ProgrammiererDebuggingProgrammbibliothekAutomatische HandlungsplanungBenutzeroberflächeBenutzerbeteiligungWeb-DesignerSchnittmengeMessage-PassingOrdnung <Mathematik>Front-End <Software>BimodulVorlesung/KonferenzComputeranimation
27:06
ProgrammiererFront-End <Software>Physikalisches SystemGebäude <Mathematik>MakrobefehlDienst <Informatik>ResultanteBimodulProgrammbibliothekVideokonferenzBenutzerbeteiligungLeistung <Physik>PunktwolkeFunktionalProgrammierumgebungGerade ZahlDesign by ContractVorlesung/Konferenz
29:21
BenutzerbeteiligungStichprobenumfangKartesische KoordinatenBimodulFunktionalVorlesung/Konferenz
29:55
Dienst <Informatik>ProgrammierumgebungMobiles EndgerätBimodulSoftwareBenutzerbeteiligungSystemaufrufQuick-SortBrowserHalbleiterspeicherElektronische PublikationGarbentheorieReelle ZahlRechter WinkelSoftwaretestMailing-ListeLaufzeitfehler
31:14
BimodulApp <Programm>BenutzerbeteiligungSpielkonsoleVorlesung/Konferenz
31:53
FunktionalStandardabweichungBimodulMobiles EndgerätSpeicherabzugBenutzerbeteiligungStichprobenumfangLoginSchnittmengeWeb logVorlesung/Konferenz
32:36
QuaderProgrammierumgebungLesezeichen <Internet>StandardabweichungGrenzschichtablösungFunktionalLaufzeitfehlerRechenbuchSystemaufrufBenutzerbeteiligungMicrosoft dot netSpeicherabzugProgrammbibliothekBimodulLesen <Datenverarbeitung>SoftwareGewicht <Ausgleichsrechnung>Vorlesung/Konferenz
33:22
ProgrammierumgebungReelle ZahlGüte der AnpassungLogarithmusMultiplikationsoperatorPunktRichtungHardwareRechter WinkelRechenschieberBitZoomCodeInteraktives FernsehenBimodulMailing-ListeLeistung <Physik>StichprobenumfangSpielkonsoleLoopFunktionalKartesische KoordinatenElektronische PublikationInterpretiererLaufzeitfehlerBenutzeroberflächeBenutzerbeteiligungMini-DiscLoginProgrammschleifeProgramm/QuellcodeComputeranimation
36:28
Open SourceFacebookGerade ZahlLaufzeitfehlerBenutzerbeteiligungBimodulMultiplikationsoperatorFormation <Mathematik>Vorlesung/KonferenzComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:08
Can you all hear me? Okay. Just a couple of things. One, I am not using Keynote. So we'll
00:21
see. I'm also not a front end guy. So I want to set the bar really low. I don't have fancy animations or any of the really good stuff that the previous presenter's slides had. So I would do this all from a terminal window if they let me. So I've been using
00:41
Rust for about two years off and on. I just recently finished a WebAssembly book that uses Rust. My day job is pretty much all go. I'm a huge Elixir fan and I've been
01:01
working on it. It will take a few seconds just to troll the previous presenter about OTP having less than 10 microseconds called start time. Just saying. And then I'm also, like I said, I'm a back end guy. Distributed systems are what I do. The less user interface the
01:22
better for me. So it makes me talking about WebAssembly a little interesting. So what I want to make sure that you get out of this is some hopefully some curiosity about what WebAssembly is and more importantly where you should and shouldn't use it. Did anybody
01:42
go to the workshop yesterday on WebAssembly? Okay. A couple. Other than the references to WebAssembly that you've had here, how many people are familiar with WebAssembly already? Okay. So that's good. That's better than usual. And again, this is a lot of this
02:06
comes from me being a back end guy. But I want to kind of focus on the idea that WebAssembly isn't just a brand new way of doing JavaScript. It isn't a JavaScript compiler or just
02:23
another fancy flavor of TypeScript. And I personally think calling it WebAssembly and having the web name in front of it is doing the technology a disservice. And again, so hopefully you'll come away from this trying to find ways to
02:42
build WebAssembly modules in Rust and even host them in Rust. This is a fairly opinionated slide born of my hatred of front end development. What we have with web development today
03:01
is a lot of fragmentation. We have to deal with browser compatibility. We have to deal with different build environments, TypeScript, JavaScript, all the other scripts. Our applications are getting bigger. They're getting slower. I'm sure we all use Slack.
03:24
I don't really need to add any more commentary there. As the web becomes more powerful, humans expand to fill whatever space they're given. And we're doing the same thing with our web technology. And so the more power we have,
03:45
the more power we waste. And I think there's a better way to do it. Not a better way to waste power, but a better way to build applications. And as a back end guy,
04:00
just the amount of tooling and setup that's necessary to even get a basic hello world running on the web now is just ridiculous. The node modules directory needs to go away. And I think that WebAssembly can get us there. It's certainly not going to replace JavaScript,
04:25
sadly. It's not going to replace node or the node module directory. But hopefully it will give us a way to get some of the benefits of the Rust language and bring those to the front
04:45
end and the back end as well. So we've been over we've seen a little bit of what WebAssembly is. It's portable. It's a standard binary format. Everyone familiar with what a stack machine is?
05:05
The silence means I'm okay. So when we run virtual machines, we can essentially run stack machine or register machine. And it just refers to the difference between how we pop instructions off and how we access and read the data that we need. And WebAssembly, along with
05:26
Java byte code and the .NET runtime are all stack machines. The WebAssembly is safe and isolated and its memory is in a sandbox. I'll get to security and hopefully again trolling the
05:49
presenter about how secure WebAssembly can be in a couple slides. But one of the important things here is that you can compile to WebAssembly from
06:01
any of the supported languages. And when I started writing the WebAssembly book, that was essentially two languages, Rust and C or C++. And now you can do C, C++, Rust, Go. There's a couple of other ways you can do it. You can for whatever reason compile JavaScript
06:25
into WebAssembly. I'm not really sure what niche that's trying to fill, but it's possible. You can then interpret WebAssembly in dozens of different languages. And I think this is the
06:40
more important part, that while we all just assume that WebAssembly has a runtime, so we think the browser or the V8 engine, that's just one of many possible runtimes. And it just happens to expose a JavaScript API. Go can host and run WebAssembly modules,
07:02
so can Rust, so can C. When you leave here and you immediately feel the need to Google WebAssembly technology, there's a couple of keywords that you can search for. I'm just
07:21
trying to save you on open tab space on the browser here. The module is the portable binary format. It's the WebAssembly file, the .WASM file. WebAssembly has a concept of tables, and at the moment the tables are only there to allow us to do function mapping. I think
07:45
the spec has more room for advancement there, but it's not really an area that I've dug much into. Linear memory, just big blocks of arrays, and that's how WebAssembly accesses its internal
08:00
data. In the browser, you can give WebAssembly linear memory, or you can take it from the WebAssembly module. So depending on how you want it set up, you can choose to share memory. And some of this goes to security. WebAssembly can only access the memory that utility can access,
08:25
so it's only as secure as the host environment. Admittedly, JavaScript has a number of ways to be exploited, but if you're running WebAssembly in a more tailored fit environment, then you can
08:42
make it as secure as you want. A trap is just essentially WebAssembly terminology for handling an exception, and imports and exports are the two most important things that WebAssembly does. Imports refer to the host environment feeding WebAssembly hooks so that it can do things,
09:06
and then exports, it refers to WebAssembly, the WebAssembly module exporting functions so that they can be called by the host. WebAssembly has four data types, and that's it.
09:23
And I just, I assume we all sort of knew this, but I want to point out that all of the other fanciness that we see sitting on top of WebAssembly is smoke and mirrors. It's all generated code. Being able to compile Doom and run it in WebAssembly while fun and a great way
09:43
to spend a day at work is all code generation. There's nothing really WebAssembly about it. So we have two integer types, 32 bit and 64, and we have two float types. Those are the only
10:02
parameters you can accept on a WebAssembly function, and those are the only return types. So why do we want to use WebAssembly other than just the fact that it's new and shiny and that's what we're attracted to? For me, I think one of the biggest
10:24
reasons is portability. We have, we've always been, we've been given this promise of write once, run anywhere since the beginning days of Java, and we didn't get what we were promised.
10:40
The .NET framework promised it. We didn't get that either. .NET core is closer than Java was, but it's still not really the vision of having this universal binary format that anything can execute. And I think WebAssembly actually gives us a chance at finally having that.
11:02
WebAssembly is fast. Through some details about how the virtual machine works and how stack machines work, it's extremely fast. But like I said, without the imports and exports, WebAssembly is really just a really fast calculator. It can do very little other than
11:26
add and subtract and do math operations. What gives it its power is the host environment. WebAssembly is secure. Like I said, it's as secure as its host environment.
11:46
You can secure the memory so that it can't be tampered with. You can secure the WebAssembly module itself. The spec has room inside the binary file for I forget what the metadata is called,
12:02
maybe just metadata. You can add a digital signature to the file so that you can verify that you own or you produced that file. WebAssembly is safe. Again, it's a, in a browser, it's essentially a sandbox within a sandbox. It's compiled, which means we get
12:23
all of the benefits of Rust's compile time safety and type checking. It's compact. I think someone said yesterday that, you know, WebAssembly's format was specifically designed
12:41
for download over the web. And it is surprisingly small. I actually meant to put harp on that one point. And WebAssembly is largely language agnostic. As long as you build something
13:03
that can create a binary that conforms to the spec, it doesn't make any difference what language you wrote it in. And it doesn't make any difference what language is running as the host, whether it's a browser or a Rust console application or, as I'll mention in a little bit,
13:22
even serverless functions. Does anybody really need me to go into why we want to use Rust for this? I do run into this problem when talking to different people who aren't at a Rust conference.
13:45
And confidence, safety, performance, one of the things that I think people don't give Rust enough credit for is the expressive nature of the language itself. In many cases, when porting code from Go to Rust, I've actually had the code become
14:04
more readable, not less. And people just assume, well, it's a systems language, so obviously it's going to look like line noise. And that is a really old reference, so now you all know how old I am. So I was looking for an analogy for what WebAssembly is, and
14:31
Feynman had this saying where you don't really know a subject unless you can explain it in very simple terms. And so for me, WebAssembly is portable brains. I can take the brain
14:44
out of one thing and put it into another, and assuming those two things all share the same set of appendages, it should just work. So one of my brains could be running inside Kubernetes as an open FAS function, which I've actually gotten working
15:09
at 3 or so in the morning today. You could host this portable brain inside Firefox. You could
15:20
host it in a Raspberry Pi. You could host it as a command line application or just a server application. One of the things that I used to do before my current job was I wrote autopilot software for search and rescue drones. And you can imagine how hard it is to test
15:43
your autopilot software when it's designed to control physical motors and read from 10 or 15 different sensors on a device. And if I had access to WebAssembly then, I might still have
16:01
access to WebAssembly. What we get with WebAssembly is the ability to take that brain out of the physical device, maybe it's a drone, and put it into a test artist. And I could literally run simulations for this drone in a web browser. I could run it in a build pipeline
16:20
through an automated test. Or I can run it on the physical device. And I can't think of any other technology, whether it's Java or .NET Core or anything else, that gives me that type of affordability. I could write it all in C, but no one wants to do that. So the first thing I
16:42
want to show is what ugly WebAssembly looks like. We all need to know what people keep telling me to stop showing the ugly WebAssembly code because it's definitely not pretty. But I think we should know, like the fact that WebAssembly only has four data types and the fact
17:03
that WebAssembly can't do anything that the host won't let it do, we need to know what our code generators are building for us so that we can have an appreciation for when we do get Doom running on the web, we know how much is magic and how much is running inside WebAssembly. So let me see if I can bump this up. I had this all set
17:32
up in demo mode and I couldn't sleep and started coding and went back to the wrong font size. So this is what the text version of WebAssembly looks like. Has anybody seen
17:45
this type of code before for WebAssembly? A couple. So the good news is you don't have to write this by hand. This is a text version of the byte codes that are being read by either the browser or whatever runtime host you're in. And just to kind of reiterate,
18:09
the data types on these function parameters can only be integers or floats. You can only do and then you've got exports. So this makes this function called add available
18:24
to the host. And so if my host is JavaScript, I can run this function and you can see there's some JavaScript here. This is just straight up regular JavaScript that just happens to be compatible. And I believe most modern browsers all support the WebAssembly standard.
18:50
So you should be able to run this anywhere unless you're in an enterprise and all of your customers are running IE4 or something. And that's not a joke. That's my nightmare.
19:06
So basically we're loading the binary file up and then we're using the JavaScript WebAssembly class. And you can think of this as that one of many run times. This WebAssembly instantiate
19:24
is the JavaScript run time for hosting a WebAssembly module. And I'll show a Rust run time for hosting WebAssembly module. But if I were to run this in a web browser, you would see this in the console and it all just looks as you would expect.
19:43
But the point here is that anything beyond what you see here and the ugly WebAssembly that I just showed is all code generation. And whether it was compiled by Rust or Go, it's all going to end up, at least today, looking something like this. And
20:07
as the WebAssembly spec grows and we get potentially more data types or more robust ways to share data with the host, then theoretically our shims will shrink while our developer
20:21
experience gets better. So has anyone, I think there were a few hands from yesterday, but who has compiled a Rust application or library into WebAssembly? So this should be,
20:40
this should also be a bit of a review, but I want to continue to sort of building on the same code. So this all looks pretty simple. This is just standard Rust. We saw in a couple of presentations today the keyword which we use for FFI and pretty much all of the rules and
21:10
guidelines and patterns and practices that apply to FFI apply to designing the public interface for your WebAssembly module. I know there's differing opinions, but I tend to try and
21:26
isolate the piece of my Rust code that sits at the barrier between Rust and the host and that way all of the rest of it can be compiled for regular Rust use or for FFI or any other reason.
21:44
And we saw samples of that earlier. And so to run this, we just build it as a WebAssembly module and we could copy this file into our directory and run the same thing from
22:02
WebAssembly or from JavaScript and prove that we get the same results. I don't expect to have much spare time, so I'll skip that demo and you can just sort of wave my hands and you can accept that that stuff works.
22:23
So JavaScript integration for the one or two front-end web developers left in the world is fairly important. And one of the reasons why I think Rust has an edge over some of the
22:40
other programming language communities is the libraries that it has for manipulating and interacting with JavaScript. So it's been mentioned a couple times today as well as yesterday during the workshop that Wasm bindgen is using macros to generate a whole bunch of code and hopefully
23:12
now you've got a little bit of perspective on what exactly Wasm bindgen is doing when it's generating the code. At a low level, it's adding functions to your WebAssembly module that
23:26
can then be called again by the Wasm bindgen CLI to give it the metadata it needs to generate your JavaScript shims. And sadly there isn't currently a version of Wasm bindgen that generates that automatically generates a Rust host, so we still have to do that by hand, but
23:47
maybe someday. So the two things that generally people use that get the biggest reaction in JavaScript integration is you can import JavaScript so that when it's imported it just
24:06
looks and behaves like it's regular Rust and you can export native Rust so that it appears as regular JavaScript. And the real power of this library is how seamlessly it bridges that gap
24:21
between the two so that when you're looking at JavaScript, you're not thinking, oh, this JavaScript came from Rust, like some other transpiling libraries tend to do. They have some of these weird after effects. And again, Wasm bindgen generates a bunch of these
24:41
JavaScript shims to allow your code to talk to JavaScript. JS sys and web sys are just essentially crates that define things that you're going to need to talk to JavaScript. So your basic JavaScript primitives, functions like console log, web sys has the bindings that you need in
25:04
order to traverse the DOM and do manipulation, access some of the other functionality like audio. Has anyone seen JS sys before, used it? A couple. Essentially you can think of it as
25:23
you've got this JS sys crate prefix and then inside that crate you have access to Rust functions and native Rust structures that will eventually do their JavaScript equivalents. This will actually call the JavaScript date now function. You can represent JavaScript native
25:47
null, create native JavaScript arrays, everything that you need. Web sys essentially gives you access to the window and then through that you have access to the DOM. I don't have on there.
26:11
So one of the other libraries that you're, so raise your hand if you actually do front end development. I know it's rare, but if you do front end development. So if you're planning
26:23
on doing, if you're planning on exploring WebAssembly and you want to build a user interface, you owe it to yourself to go look at a library called YEW. It's a Rust native library that gives you a React Redux style set of message passing in order to control
26:46
a virtual DOM and it all compiles into WebAssembly. And if I have to do front end web development, doing it in Rust isn't such a bad thing. So how many have you, how many have
27:03
hosted a WebAssembly module in Rust? All right, well you guys need to stop raising your hands because. So as I said, I am obviously biased towards back end development and distributed systems
27:24
and cloud and so being able to host the WebAssembly module in Rust is where I think some of the real power comes from. Not just because I like hosting stuff in Rust, but because if Rust can host it, then so too can so many other things. Like I said, we don't currently have a,
27:48
we don't have a tool that generates all the magic smoke and mirrors that we do for JavaScript. So a lot of this stuff is still a little rough around the edges. There was a crate or there still is a crate called WASME. I'm sure it's got a better pronunciation than that,
28:02
but it came out of I think Parity's work with blockchain and they were using it for blockchain contracts. And as a result, the developer experience isn't designed for what I would consider just common everyday use. It's not a super friendly library.
28:26
There's a new one that sadly showed up after I finished writing my book called Wasmr, it's got a couple of nice macros that make it really, really easy to host WebAssembly modules
28:45
in Rust. So like I said, you can use it for serverless, embedded, IoT, microservices, being able to use WebAssembly modules everywhere that you used to be able to use a Lambda or a
29:02
cloud function is pretty appealing. I mentioned briefly that you can sign the modules so that in your production environment you can guarantee that a particular WebAssembly module came from who says it came from and can do what they claim they can do. Let me just take a quick look at Rust embedded, here we go.
29:35
So I've got a sample here that's just a Rust application that runs and interprets a WebAssembly
29:43
module. So the module just does, it's got a function that logs a string from inside the WebAssembly module, so this is an export. And then there's a function that will be exported called do work, and these imports and exports operate the same way as they would if I were
30:08
to be running this in JavaScript. So I can compile this to WebAssembly, run it in a browser, and then I can run the same file unmodified, which is the real test of portability inside
30:23
a Rust host. And to do that, I just use the Wasmir runtime crate, and obviously I'm just hacking around to grab the bytes. You would get them from disk or you'd
30:42
get them injected through a network call in some sort of serverless environment, there's all sorts of ways you could get these bytes loaded into memory, but this section right here is essentially where all of, or most of the WebAssembly magic happens.
31:03
Setting the imports is explicitly telling your WebAssembly module what it can and can't do. If it's not in this import list, then your WebAssembly module can't do it. If you don't include the ability to print to standard out through some import,
31:20
your WebAssembly module can't do it. If you show me a JavaScript app that is running a WebAssembly module that prints to the console, the only way it's happening is through something like this, and it's because we're getting so much of that JavaScript generated
31:42
for us that we just kind of take it for granted. And who has heard of WASI or was aware of the recent announcement? Okay. So not too many. So right here I have a function that's being exported, and it has a name called logster.
32:04
That's obviously proprietary and only works on my sample. I lose portability when I take this module out of my Rust host and try to run it somewhere else where I don't get the logster import. So what WASI is trying to do is define a set of standards that can be injected
32:23
into the imports of a WebAssembly module so that we do have portability. If we have WASI core, we should be able to assume that we'll be able to print to standard out from our WebAssembly module or read from a file or make a network call. And along the same vein
32:48
is how the .NET core libraries are separated into separate functionality. The idea hopefully is that we'll have WASI run times that do just the basics. You know, essentially just running
33:06
a calculator in a box to giving it standard out so that we can run it in serverless environments to adding network access. And one of my favorites is hopefully we'll see WASI standards for
33:22
embedded stuff like GPIO and I2C and other hardware interactions. But it all comes through this list of imports. And then just like in the JavaScript, we call instantiate and we can run it. We'll see if, yeah, I realize that's tiny.
33:51
I'll zoom in on it as soon as I can find the code sample.
34:10
So okay. So it's getting cut off a little bit. So I just ran my Rust
34:25
console application that read WebAssembly file from disk, instantiated it through an interpreter and called do work which has a for loop on the inside of the WebAssembly module that's calling the log function and it calls it once inside each of those loops. So you can see
34:45
that the WebAssembly module asked the host to log this text. And like I said, you can't the WebAssembly module can't do that unless you give it that functionality. And so when we have
35:02
special run times for running WebAssembly applications, Mozilla's got one, Fastly just released one, and I'm sure that there will probably be another five or ten more fairly soon that are all specialized towards running WebAssembly modules in certain environments.
35:25
This is I think where the real power of WebAssembly and Rust start to shine. You can do user interface if you want, but this is the good stuff right here.
35:48
So I wanted to get through the slides and just show a little bit of code so that hopefully I'd have plenty of time for questions. So yeah, the main point is WebAssembly is
36:06
a great new technology. It's still early days, so there's still some rough edges around it, and the direction is a little unclear, but I think it has a promising future, especially with Rust, but it isn't a cure-all. Running WebAssembly everywhere doesn't make sense, so
36:26
I think the next steps for all of us is to just figure out where it makes sense to run these WebAssembly modules and in what run times we should be running them.