 Well, it's been a great day. Thank you again for joining us online and for in-person. It's an interesting way to run something like this, but it has been a lot of fun. I feel like we've hit a lot of topics today. We've hit everything from machine learning to networking to programming languages, data storage, and just about everything in between. And I think that's a good testament to the potential we see in WebAssembly. So I'm Matt Butcher. I'm going to be the moderator of this panel. I'm going to pass things down and have each person introduce themselves, and then we'll kick it off with a couple of questions. I, of course, have some planned. If you have some good questions you'd like to direct to the panel, just raise your hand. Or let's see, Ralph, you can raise your hand for any of the ones on Slack. And I'll try and get those in there as well. Again, thanks. This is a lot of fun, and this is going to be a fun way to kind of close out the day. So without further ado, you want to introduce yourself, Bailey? Sure. My name is Bailey Hayes. I'm a principal software engineer at Singlestore. And I've been working with WebAssembly for a while, most recently, in a database. Awesome, yeah. My name is Oscar Spencer. I am a software engineer at Suborbital Software Systems and also the lead maintainer of the Green Programming Language. I'm Taylor Thomas. I am a director at Cosmonic. I've been working on WebAssembly for about almost two years now, a year and a half. Do a lot of things with Crestlet, Bindle, some of the things in that area, and with WasmCloud. So I thought kind of a fun way to kick things off would be to ask each of you your superhero origin story for what got you into WebAssembly and sort of what your journey has been thus far. Because I think with a technology like that, we might see answers from all over the place. And again, I'm just going to hand it off to you, and we can kind of go down the line. OK, so many of you might be familiar with a technology called Flash. If you're young, maybe not, we had a lot of stuff in Flex, which is basically Flash for building web applications. And part of that was very vast graph data visualization library. And we at the same time had a bunch of things, like mobile was starting to become a thing, people had some rumblings maybe about HTML5. And the problem was, OK, how do we pivot quickly and deliver something in, you know, I think I was given six months. And so I like span the web. There's this thing called PNACL. There's this thing called Asm.js that was kind of hacky, maybe crazy. And we had C++ code that we were working on for our mobile applications. So I took our C++ code, used the thing called Inscripten, which is awesome. Thank you, Alonzekai and Mozilla. And we ended up with something shipping that year. And it was really great, performance in IE, non-existent. And the other browsers, it was really cool to watch, support get added every time. And the performance just kept getting better. And then we were able to swap over to WebAssembly once it became a standard. Yeah, for me, it was 2017, mid-2017. And WebAssembly had just been turned on by default in all major browsers. And for me, you know, being a person who is interested in programming languages, I saw this as a unique opportunity. This was a real opportunity to bring new languages, or even existing languages, to the web without needing a compiler to JavaScript. I mean, granted, you know, I'm a fan of languages that compile to JavaScript. But it was exciting to have a brand new assembly language where the world was our oyster. We could do literally whatever we wanted. And so at that point in time, I said, you know what? I'm going to build a language for WebAssembly. I'm going to make it happen. And lo and behold, here we are years later. And I'm still doing it. Still loving it. It's a great time. Yeah, and a very interesting language it is. I do love grain. So my superhero origin story, though, yours sounds much more noble than mine ever will. So I was actually coming out. Before I was over at Cosmonic, I actually am a Deus Labs alum. Worked with Matt and Radu and a couple other people you've probably seen in the community. And that year, I had actually joined the team officially. And this is 2019. I was working on Helm 3. So Helm 3 was taking over my life and everybody's life, who was working on Helm. And so after we were all like done with that, I got into kind of that December timeframe and we're working on Cresslet. And let me tell you how hacky it was. It was hacky. You could only do something in one name space. It was gnarly. And it was just, but you're going all Swedish. I was like, dirty, dirty, dirty. Just trying to get this all together. And so, but that's when I started kind of looking and helping out and trying things with it. So we were working on just kind of dabbling around. It was out there in the wild. And then all of a sudden, I think it might have been Ralph, your wonderful MC for this occasion, who put something on Slack. And I had happened to see it over the weekend. And I saw that, hey, it was somewhere in the top five in Hacker News and I was like, uh-oh. So that's where all of a sudden everyone is jumping all over Cresslet and loved it. And then I kind of took over as the project lead and have been that since working on the project. So that's really where I got into WebAssembly. It was very, very practical. I didn't get to do the whole research WebAssembly do cool hacking project day. It was like, okay, now you're in charge of Cresslet Go. So that's where my background, my superhero origin story is. I'm gonna kick the next question right back over to you as well because everybody wants to know the answer, but I don't wanna be anywhere near the person who answers it. So people ask quite frequently, is WebAssembly the technology that's going to beat containers? Are we gonna beat Kubernetes? Kind of when you look at the lay, and remember you're at like the day before KubeCon. So there's a crowd with pitchforks outside just in case. I know, I'm waiting for those pitchforks to come through the door with this. The mob to come in here, but I, so there's a couple ways to look at this. And one of the things is that WebAssembly offers a lot of things that containers could never do. So being blunt, like we always thought, oh, well it can run on any system. No, it couldn't. Docker containers just, they're a Linux technology. Yes, people who I know at Microsoft can make it work on Windows. Yes, but it's still a completely different set of technologies. But I wouldn't say they're the thing that's going to beat and destroy containers. I think there's workloads for the foreseeable future that will work better and are a better fit for containers than WebAssembly. But WebAssembly really opens up, and I think you've seen, this is why I love who's all on the panel here. Like there's so many different aspects of WebAssembly that come in here that like you couldn't use WebAssembly in any way to do what Bailey talked about in her talk this morning. There's zero way to do that. And then the stuff that I was talking about with Matt with Bindle, like composing applications like that, you can do it, but it's a way more complex process that involves other tools and other connection things for containers. And so I don't think that it's necessarily one or the other, but I do think WebAssembly is a better fit for a large number of use cases, particularly as it matures. Yeah, and if either of you have anything you want to jump in on there. Wise. Look, the door just opens. Yeah, and I'll just go on down the line. Actually, this one I would like everybody's input on, but Oscar, I'll start with you. Once we get to a standard bytecode format, standard runtime, do you see, what are the implications you see for what programming languages and developer experience using those programming languages is gonna look like over the next, let's go with like five years so that none of us has to implement anything in the next year or two before the next, yeah, what do you think, where do you think it's going from here? Yeah, I think it's definitely interesting to look at, right? I think the first point that I would definitely look at is the debugging story in WebAssembly. I think that's the number one complaint that we hear from folks is it's really hard to debug my WebAssembly code. For a hot minute, we had support for source maps in WebAssembly and that's gone now. And now it looks like we're gonna be largely using Dwarf for everything, which is fine. It'll work in WebAssembly. I have thoughts and feelings about it, of course. But yeah, I mean, I think overall, the beauty of WebAssembly is the fact that it is a binary format that we can get any language that we want to compile to it. So if you're writing Python, right, you're gonna get to use all the tools you know and love with Python. You don't have to do anything specific to WebAssembly. And that's the same thing with Rust. Everyone uses Rust and loves developing in Rust, but that's not because of WebAssembly. That's because of Rust. And at the end of the day, LLVM is the true champion and makes sure that we can actually target WASM32 WASI, right? So overall, I think how it's going to morph is we'll start seeing new tooling come out to better help us work with our WebAssembly code. But at the end of the day, we don't want developers worrying about the fact that it's WebAssembly, right? Like I want my developers to focus on whatever they're trying to build. Like I don't care if it ends up being x86. I don't care if it ends up being WebAssembly. If WebAssembly is the technology that makes sure that all these amazing things happen, then that's the beauty of WebAssembly shining through. But it's not the goal. We don't want developers to feel like they have to do anything special because it's WebAssembly. And if either of the other two you want to jump in on that one too before I go. Man, that was such a good response. I totally agree on the debugging story. I will say it's better than it was with ASM.js. I definitely fixed a compilation error between two different optimization levels. And I only found it by stepping through the basically assembler. So if I never do that again, that would be really cool. But the other side of it, I totally agree that it's a little interesting that we're this excited about a compilation target. You know, I mean, I'm super into it. It's just whenever I explain it to anybody else, they're like, I mean, it's secure and it's all these awesome things and it's going to enable so many different types of workloads. And the reality is, yeah, five years from now, I don't know that we necessarily will be talking about wasm. We'll just be talking about all the cool things that we've enabled. Yeah, I've heard the good technologies vanish into the background argument. And this is one of those cases where I think I hope that's true. If you queue up any questions, just raise your hand, but I'm going to do one more before that. Because I do want to make sure I ask this question because this is something that is really exciting to me based on your presentation earlier today. You know, I think, let's see, databases have been around since the 1950s, I think, with SQL being what, 70 something, which is a big relief for me because that means at least there's something older than I am at this point. But it seems like every so often we hit sort of these milestones where we see a big change in the way that we think about how we're going to manage data. Right, and we saw SQL being, of course, the first and then more recently no SQL databases and then after that kind of big data and map reduce and techniques like that. I'm curious what your thoughts are on, you know, where we've been most recently, the kind of stuff that you all are doing now and if you want to just wildly prognosticate about what kinds of things you think are coming in the future. Okay, yeah, so I'm fairly new to the database world, so forgive me, database experts that are out there. I definitely have somewhat resisted learning a ton of SQL. And when I was in college I was learning MongoDB and that was because in the like 2010 range that was the hotness. Everybody's doing no SQL because we need to be able to scale our workloads out. We've got things running across the globe. And now we kind of realized that we can design databases in a different way. Relational databases, of course, existed definitely in the 70s. I'm not going to go back to the 50s. Definitely in the 70s. And we realized that this type of having a relational database and having those types of structures makes it really powerful for finding answers to things. And that's why you're seeing all these different new databases crop up that are being able to handle these new types of workloads. Some people call them new SQL. Some people are calling them HTAP, trying to do this type of blended thing. And the key difference I think right now is just the breadth of data that we're operating on and all the different data sources that we're getting information from. Like we're gonna be streaming things from IoT devices and on the edge in your warehouse, right, everywhere. So if I'm gonna just like participate about how things are gonna be different I think most people are going to be building against a single platform. And those details will again fade back into the background. And I really hope that all these applications underneath are built with WebAssembly. So for those of you that are following along in Slack throughout the day, there have been t-shirt lines that got offered in talks here and there. I think currently, Oscar, you're actually leading at having two in one talk, starting with what was it? I love pattern matching, I think, yeah. But one of them that I thought was really interesting was we should start thinking about bringing the logic to the data instead of the data to the logic. And that one too, what you were just saying there, a lot of that resonates there. Before going on, does anybody else have any of those kind of favorite clips from the day that you wanna call out out loud? I'm just queuing you up for the question next because I'm basically stalling. Ah! Tell me what, let me interrupt. Okay. If you can, are we on here, are we on? So we have a couple of questions, but there's one from Anthony who says, where do you see that it's a different take on the future of Wasm? Where do you see the future of Wasm on the web? Will Wasm actually be more useful on the back end than its original front end use? Or do you think there's still a great amount of potential for Wasm on the web? I feel qualified to talk about this one. Yeah, I mean, even just looking at grain, back in the day, we honestly thought that WebAssembly was going to only exist in the browser. There was no thought that WebAssembly was going to exist on the server. And especially now when we see where things are going, where folks are loving using WebAssembly in server context, there are people fighting to make sure that the browser context is not left behind. Some people will die on a hill to make sure that WebAssembly in the browser happens. And I think there's an absolute ton of potential for WebAssembly in the browser. Of course, the major use case, for me, thinking about languages, is yeah, I want to be able to bring my language to the browser. I want all languages to be able to bring their language to the browser. I don't want everyone writing JavaScript forever. JavaScript, it's a great language. It's an amazing language that has come so far for being designed in a week or two. It's really good where we've come, but we can do better. We can bring languages that people have been incredibly productive in to Web context. I think the moment we start seeing better support for all these languages in the browser, there's going to be a huge, huge boom that you haven't seen the likes of before happening in the browser. It's definitely on its way. Keep your eyes open because it's going to happen. Especially with, we have so many WebAssembly proposals now for especially like bindings to the DOM, bindings to be able to interrupt with JavaScript a lot easier than we do now. Reference types is already in. We can already start doing a lot of these things now, but a lot more is going to happen. And I do think we'll get some momentum behind building WebAssembly libraries. And once that happens then it'll be easier for browsers to leverage the same kind of libraries we have. I think one kind of cool thing that came out of Node and NPM was that we went from downloading random tar balls off the internet to get pieces of JavaScript functionality to having package management that worked really for both the browser situation and the server situation. And I'm optimistic that we might actually hit that same kind of experience with WebAssembly over the next few years. And even just to add on to what I've said, looking at the module linking proposals, looking at the interface types proposal, and looking at bendals, right? Actually, we're going to get to a really interesting place where you're going to be able to write whatever library you want in whatever language you want, consume it from any other language you want. So maybe you need that cryptography library and I love grain and death, but I want someone to write that cryptography library in Rust. Like please, write that in Rust. And then let me bind to it so that way I can provide that to all of my users, right? But then maybe you don't need to have that super low level systems processing thing and you want to write some sort of high level thing and you can write that in grain or you can write that in the next super high level language for WebAssembly that comes along. And these things will all be able to come together. And then we're going to see the true dream of the web of having, and folks who talk about web components, well, we're going to actually make a real reality of it. It's only taken 20 some years. All right, we have a couple others and you got a choice. You can have a speculative question or a provocative question. Well, provocative sounds. Okay, there we go. We're going to be provocative. Is Wasm going to be the new lingua franca to replace C given another 20 years? And Taylor's going to answer that because he picked provocative question. Thank you. Apparently question provocateur, apparently, but no, so I think, I don't know who asked that question but I think that's a, I would like to reframe it a little bit, which totally sounds like a dodge. I'm not dodging it. The real thing with WebAssembly is that it isn't a language per se. It is, but in the way we've been talking about it here, it isn't a language, it's a compilation target like Bailey was saying. And we're all excited about it being a compilation target. And so I think it will become the lingua franca of running things and what we compile to, but I don't think that will determine the language we write in because I have tried writing Watt files and it is not entertaining. So like that, I don't think WebAssembly in its raw form will become the lingua franca, but I do think it will become the build target that things will go for in most cases if it continues evolving the way it does. And that's where, this is where I'm going to latch in a little shout out to the community and people who are listening here. That's what we're looking for help on. We're looking for people to do things like use grain, try out the crazy features that single store is doing, give us feedback on Bindle. Like whatever it might be, whatever interests you in the WebAssembly community, it's to go out and try it because we need the effort from people who are doing these things because there is no way just a few of us can think of all the different edge cases and ways that this could be used. And so that's where I throw in that little push for people to try to get involved in whatever way you can, even if it's just trying it out and then opening bug reports or issues or improvements that you would like to see. So we could do the speculative question just to throw it out there. There aren't any other questions currently, but the speculative question is a little bit different, which is do you think that wasm has the potential to achieve native level performance given enough time and potentially custom hardware support? So pretty speculative, go for it. That was like my back pocket question that I was gonna ask if everything got deadly silent in here. I think you should have to answer it, Matt. No, thanks. I think I'm pretty optimistic on that. I think when the JVM was going through some of its early iterations and JIT technologies took off, then you start to see, we started to see performance go in directions we had not anticipated. Some of the like re-profiling and dynamic recompilation stuff was super cool. And with a lot of the ahead of time compiling stuff in WebAssembly, I'm excited about that too. But that last little bit in that question is what really has me excited. The proposition that we might be able to push some or all of this down to a hardware layer or even be able to implement hardware layer memory boundaries or things like that that might allow us to take advantage of very low level hardware acceleration would be a lot of fun. And you're nodding, so do you have anything you wanna add because I'm making stuff up as I go, Oscar? Yeah, I mean I think that you're exactly right. And I do think we're gonna see amazing performance out of WebAssembly because remember, it's just the beginning, right? There's so much more work to be done in WebAssembly. There's so much more to do with WebAssembly compilation, right? Like there's so much more to come here. And I guess the other thing too that's really interesting about WebAssembly modules is they're very easily introspectable. Is that a word introspectable? And so you can take a look at it, you know exactly what kind of functions it exports, you can figure out where it's what it's trying to call and what it needs. And so like I think that to me sounds like though I am not a performance expert that you could really, really start to introspect the module and just ratchet down all the little bits and loose pieces to make it just run super smoothly on whatever you need to do. I mean just the fact that the thing I always point out to people, and if you've been talking to me you've heard this so I'm sorry and you're hearing it again, but WebAssembly, one of the big overlooked parts of WebAssembly is the ability to choose at runtime the characteristics of it. You can choose when you run the thing if you want it as interpreted, JIT, AOT, whatever it might be. And so that combined with the fact that you can just look at a module and really like just crank it down and there's even things right now like Wazemopt that just, I was doing some testing with Wazemcloud actors the other day and we were getting 20% savings just from using that. And so I think there's going to be a lot of different ways we can optimize here though what that will look like is completely out of my ability to guess, but I do think there's gonna be multiple ways to really ratchet that up. So kind of building on that and going in a slightly different direction and security's always a big deal for all of us, right? And we've heard in a couple presentations today some of the good security features of WebAssembly that make it attractive. One of my favorite things about WebAssembly is that we basically built something that matched the browser security model and then went, oh, this matches all these other security constraints we have, but what kinds of things do you think we could do better? What kinds of things were you? Anything about security that keeps you up at night or that you're excited to try and solve? I'll take that one. So we're adding a bunch of different extensions with Wazzy with each introduction of a new ABI, that's a new surface area of attack, but at the same time, like one of the number one questions that I'm getting from the people I'm talking to is like when can I get ahold of the socket? When can I make a rest call? And if I enable it in a certain way that's not secure and not well thought out, like support for content security policy, validating my headers, making sure all the things that are already in place in browsers today, then I feel like that vector does kind of keep me up at night because I know I want to enable it, but I don't want to turn it on in my database until somebody with a very strict security mind has also validated it. Yeah, I think all of my worries around security have to do with module linking as it stands right now because typically right now for anyone who's not using the official interface type spec and module linking specs, you're kind of just rolling your own thing and you've got different Wazzy modules coming together all sharing a single memory, right? I can wazzymy32.load whatever I want from memory, right? And that's not great, but with where module linking is going, a lot of these problems are being solved the way interface types is going and multiple memories in WebAssembly. All of this is being solved. So, I mean, overall I think we have a, as I've been saying, we have a bright future ahead, right? But yeah, I think it's not too much to worry about right now. And it's, the thing about sharing the memory space is honestly what scares me a little bit. I remember the first time I went trawling through the wasm time code and this is not for any wasm time people listening, this is not like something unique to wasm time, it's the one I was trawling through at the time. And I was sitting there going, oh, that is just a pointer to a random place in memory. Okay now, well, giddy up, guns in the air, shooting on a horse, kind of wild west thing. I'm like, okay, that's a little scary. I mean, it's very well sandboxed and put together, but the fact that you are just taking a random pointer to a random block of allocated memory screams to me of being something scary. So I can see there being some possible issues there that worry me. And I think there's going to be certain types of workloads that need really, really strict memory boundaries. And there's already tools that exist to do that and I think how they integrate in and if they can make them integrate in seamlessly will be the solution to that. Yeah, and I think, yeah, a good distinction to make in some of these is the danger to the guest module from itself or the libraries it loads and the danger to the hosts that's running the guest module. A lot of the ones we're talking about here are the guest module being able to do bad things to itself. Some of these could potentially become, we expose an API into the guest module that allows it to make system calls. That's when I think it does start getting dangerous. But one of the things that's really, building on what you said, Oscar, one of the things that's really exciting me about the way some of the component stuff is going is that it looks like if things play out the way that they're moving right now. Say you have the typical case where open SSL has a bug in it and in container land that means we have to go rebuild every single container image that compiled in that particular open SSL one. And one of the things that's exciting me is that with the component model we may be able to hot swap in a patched version of open SSL without so much as redeploying things. And that would be just so great to see. I know we are now out of time. Thank you all very much for joining us today. And again, thank you to all of you who have stuck in all day online and those of you who are stuck in all day in person. This has been a fun way to do the conference. I think I'm handing it off to Ralph or to Liam next. So again, thank you all.