 All right, it's my pleasure today to welcome Eduardo, who is a developer from Tetrate, and he's presenting WebAssembly from the inside out. And if you're unaware, Eduardo works on a runtime that's really well aligned to Cloud Native called Wazeero. And I think we saw the title of this talk rotate a few times. There was going to be Wazeero from Wazeero to Wageero. But I think I love where this has landed. So please join me in walking to the stage. All right. Thank you, everyone. So this is WebAssembly from the inside out. My name is Eduardo Vaki. That's how you can find me on Twitter and pretty much everywhere on the internet. Before I start, Tetrate and Sysdig and Chinggarde are hosting the OSES security sware tonight. So if you'd like to join us, and if you want to find me at the conference, I'll be together with my colleagues at the Tetrate booth for the rest of the QCon. So let's start talking about Wazeero. Wazeero is a perfect companion for Cloud Native software written in Go, because it's a WebAssembly runtime written in pure Go. And it's sponsored by Tetrate's non-point source project. And the reason it's a perfect companion is that by being written in pure Go, you don't pay the cost of using, for instance, a Go. So you can bring it as a dependency without thinking about it twice. And because it's written in pure Go, you also get seamless interoperability between your Go host and your Go host functions and your WebAssembly binaries. So that's all because we don't need Sego. And then I'll tell you a little bit more about Sego later. Just gave it for granted. It's just a bunch of limitations. It allows you to link against native binaries. But we don't need to do that. All right, but besides that, in general, Wazeero works as a WebAssembly runtime like most WebAssembly runtimes. So we have a compilation phase and an execution phase. So compile time happens at load time. So when you load a WebAssembly binary that gets turned into an executable form, and then you can instantiate it and execute it and invoke functions a number of times. So how do we compile functions? In general, what you do is you load the binary, the WebAssembly binary. You decode and validate such binary. And then you compile it to some executable form. In our case, we compile it into an intermediate representation, an internal, intermediate representation. And this intermediate representation can be executed directly by an interpreter that runs pretty much everywhere. The Go compiler is supported. But if you run on a supported platform, a platform that we support as Wazeero developers, you also have access to a compiler that generates native code for MD64 and ARM64 on all major operating systems. This is a straightforward translator. So you get good performance, but it's not an optimizing compiler. But the good news is that we are working on a multi-pass optimizing compiler that will bring better performance as well. Now, what happens at runtime? So at runtime, you can instantiate your module, and then you can invoke any exported function, as you would expect. But how are functions invoked? So because of the way functions, you need to play a little bit with bits and bytes and the stack and registers. So you jump inside the compile code, but then you have to be able to jump in and out, in and out, depending on what happens. And that's why we call that a trampoline. So for instance, imagine that you're executing some wasn't function from your Go host side. And so we jump inside the execution of the executable code that we have generated, and then there's an error. So we return an error code from the WebAssembly side, which is compile code. We return with an error code. And then we jump back into the Go side so that this error can be handled. And what if we invoke a host function? Well, interestingly enough, it's very similar to what happens when we trap. Instead of returning an error code, however, we return some identifier that represents the function that gets to be invoked. We pull data from the WebAssembly, compile WebAssembly, which represents the parameters for the Go function. We invoke the Go function on the Go host side with the right parameters. We get the results. We push it back onto the WebAssembly state. We jump back into execution of the WebAssembly function, resume execution from where we left. And then we go on and on and on until everything terminates. But now you might wonder why a wasn't runtime in pure Go. And in order to answer that, we'll need a word from our sponsor. Do you remember the olden days when software development gave you a lot of headaches? Are you still living in the past or are you a Go developer? We bet you're in love with all the features of your favorite programming language, such as static compilation, cross-platform builds, and Go routines. But aren't you worried about extensibility? In the past, you only had one choice, use the Go. But the Go has limitation with portability, with safety, and performance. So even if you love your creature, it is just not the same as your traditional Go runtime. With Go, this is how your memory layout looks. What a mess. Wouldn't you rather prefer your memory to look this tidy? Well, join the WebAssembly revolution. Powered by sandboxing. But what if even the wasn't runtime requires Go? Well, enter was0 by Tetring. Before was0, all wasn't runtimes required Go. But was0 washes all that Go away. Was0 integrates with the Go runtime in all the ways you expect, such as supporting context cancellation. And it runs on all of your favorite platforms, even the weird ones. We won't judge you, you sicko. You still don't believe me? Was0 is so portable, you can even run was0 inside was0 so you can wasn't while you wasn't. Join a growing list of satisfied projects, such as Stopper, Humanity Shellr, which is a work in progress, Aquatribe, and more. See more at was0.io. Go was0 a star today, and get was0, become a was0. So thank you for listening, thank you for staying with me. If you enjoyed this presentation, if you can rate this session, you can find me at the Dead Red booth, and thank you, everyone. Hey, do we have any on-topic questions? Then we can go to the off-topic questions. I think saved the best for last. Thank you. We'll officially end the program for today. This was our sixth Cloud Native WebAssembly day, and I just want to thank everybody for coming out. Huge thanks goes out to our CNCF program team. Evie makes all of this work and makes it all easy with an incredible support team, but also a huge thanks to Dale on audio and the rest of the production support crew here. Tristan, everybody, you guys did a phenomenal job today keeping us on track. A huge thanks to the program committee, which is a volunteer position, by the way. Thankless, and you too could volunteer for a thankless job if you'd like, because it's time to start recruiting for WebAssembly Day EU and for WasmCon 2024, which is just around the corner. So huge thanks to the whole program committee for all reviewing over 65 talks for WebAssembly Day. It's really hard to pull together a program like this, but I hope that you agree, and you'll share your perspective on why I think this was the best WebAssembly Day we've had yet. A huge thanks to our speakers, Eduardo, you crushed it. I really think we slotted you in the right spot. Just bring us on home. And I think you are most deserved of a beer. And I think the other person that might be most deserved of award is the most mentioned person on the floor today, which would be Intel's Andrew Brown, basically the Kevin Bacon of Wasm today. You got mentioned about a dozen times or more called out for your great work in the runtime. I had a funny story where one of our investors reached out and he was like, who the hell is this Andrew Brown guy? He's in everything. He's in Waz-E-Threads. He's in Waz-E-N-N. He's in ML. So thank you for being such an amazing community member and so generous with your time. Just one quick moment, just a pause for a second on how far we've come. WebAssembly is almost a decade old, and it's now that we've finally had our docker moment, where all around the talks today and the conference, you saw people from different companies, from different runtimes, all aligning on the Better Together story, which is a single artifact that we can build an ecosystem around that is portable and takes advantage of all of the WebAssembly inherent properties. So my view has been that WebAssembly and specifically the WebAssembly component model is not just the next big abstraction in tech, it's the final abstraction because we can finally push all the rest of this complexity, start with Bailey's toilet bowl from this morning and push it all the way down into the runtime. Developers can have a better life and we can finally have technology that truly works better for everybody. Component ties has become the new containerize. You saw components today run on WasmCloud on VMware, Wasm Labs, a Wasm worker server, on Fermion Spin, and on Michael Wands, it was one of the big contributors to another CNCF project, the Wasm Edge runtime. I talked to, and the questions I asked for Istio and Red Panda, maybe WebAssembly components coming soon there too. So I just love to see the community coalescing around something that we can all work together on. Last year we had Kelsey Hightower come out and his message to us was that in the container wars we competed too early and if you were a veteran of those wars, you know that early on people were forking runtimes and trying to lay out a proprietary path forward. WebAssembly is already open source. It's already community led and it's something we can work together on and make better together. Please join us right outside the hall here for an evening reception from 5.30 to 7. And finally, a call to action. We are accepting applications for program committee for WebAssembly Day EU and a huge shout out to two related events. Wasm I.O. is on track for 2024 in Europe. It was phenomenal last year. Strong recommend. It's about two weeks before KubeCon in Paris where we're gonna have another Wasm Day and then of course we've already booked WasmCon in Seattle for August of 2024. So we've already got a huge year planned for WebAssembly 2024. Let's make it bigger and better than ever. Thank you so much for coming today. Have a wonderful KubeCon. Bye.