← Software Engineering Daily
Software Engineering Daily
WebAssembly 3.0 with Andreas Rossberg
01:01:13
WebAssembly, or WASM, has grown from a low-level compilation target for C and C++ into one of the most influential technologies in modern computing. It now powers browser applications, edge compute platforms, embedded systems,
Loading summary
Transcript76 lines
- [00:00]
Narrator
Webassembly has grown from a low level compilation target for C and C into one of the most influential technologies in modern computing. It now powers browser applications, edge compute platforms, embedded systems and a growing ecosystem of languages targeting a portable and secure execution model. Andreas Rosberg is a programming languages researcher and former member of the V8 team at Google. Andreas helped architect webassembly from its earliest concepts through its most recent milestone releases, including the groundbreaking 3.0 spec that introduces garbage collection, richer reference types and major steps towards multi language interoperability. In this episode, Andreas joins Kevin Ball to explore the history of webassembly, the constraints that shaped its earliest design, the major turning points in versions 1, 2 and 3, and what's coming next for webassembly. Kevin Ball, or K. Ball, is the Vice President of Engineering at Mento and an independent coach for engineers and engineering leaders. He co founded and served as CTO for two companies, founded the San Diego JavaScript Meetup and organizes the AI in Action discussion group through latent space. Check out the show notes to follow K. Ball on Twitter or LinkedIn or visit his website Kball LLC.
- [01:33]
Kevin Ball
Andreas, welcome to the show.
- [01:35]
Andreas Rosberg
Oh, thank you. Thanks for having me.
- [01:37]
Kevin Ball
Yeah, I'm excited to have this conversation. Let's start a little bit with you. Can you give us a bit of your background and how you got involved with webassembly and kind of what took you to where we are today having this conversation?
- [01:50]
Andreas Rosberg
Yeah, it's been a bit of a journey. So I'm a person who is kind of on both sides of the aisle in terms of academic and industrial work. I used to be more like a researcher in programming language, both hardcore theory stuff but also implementation stuff. At some point I switched over to industry, working for Google, working on the VA team, and that's one side where the whole webassembly thing started. So that's how I got involved in that.
- [02:17]
Kevin Ball
Let's dive in there. Actually, I didn't realize you'd done a lot of academic work on theory. So I'm kind of curious maybe as we go along to explore how that has influenced development of webassembly. But let's maybe take us on a quick journey of the history of webassembly. I think, you know, if we have web programmers here, they're probably familiar, but not everybody is. So let's kind of go through what was the inspiration and the different stages we've been at coming to today.
- [02:40]
Andreas Rosberg
Okay. Yeah, so a bit of history was that before webassembly on the web we basically only had JavaScript, right. And it was always clear and common complaint by many people that this is not good enough. And JavaScript has problems, as we all know. And if you want to use other languages, you have to compile to JavaScript, and that's far less than ideal as a compilation target. It also can be slow or at least very unpredictable in terms of performance. So before WebAssembly, there were already like two kind of technologies that tried to bring more like native code to the web. And one was native client that was a Google technology that allowed you to do initially at least x86 code to run that in the browser in some form of sandbox. And then a bit later, the other thing that occurred was asmjs, which grew out of emscripten, which is this tool that was able to translate C to a very stylized subset of JavaScript that engines could compile more efficiently. But that was really like very clever, ingenious hack. So it was clear that this would not scale very well. Right. Like so. And at some point then it was mainly people working on the JavaScript engines at Google and at Mozilla, so Luke Walkner and Ben Titzer in particular, who got together and started the idea of like, let's do it the right way. And that's kind of how it evolved then. And that was back in 2015, I think.
- [04:11]
Kevin Ball
What would you say are the constraints unique to trying to do this inside of a browser environment the way that it was? You mentioned, like, okay, to get fast, we had to trim down the subset and Google tried this native X86 approach. What makes compiling to a browser environment different than just running something on my laptop or server?
- [04:35]
Andreas Rosberg
So the biggest constraint of course is that it has to be safe and secure. Right? You're running untrusted code essentially on your own machine, so you can't afford like any undefined behavior or any kind of other non safe behavior. So that is like the topmost constraint that hovers above everything else. And then of course you also have constraints like the web is very particular environment. You don't have access to most of the services that you're used to from regular operating systems. Like there's no file system or anything like that. You can emulate some of that stuff, but it's not really physically there. And various other OS kind of services, right. And various programming language implementations kind of assume the presence of some of these services. So when you compile at least to the web, then some of these things have to be implemented differently and you have to be aware of these Environmental.
- [05:36]
Kevin Ball
Constraints, that definitely is a somewhat different environment to have to target. Let's then maybe look at what the sort of big steps have been leading up to this 3.0 release. So the first version of WebAssembly, what was in the box?
- [05:51]
Andreas Rosberg
So the first version is essentially with targeting customers. We already had with asmjs in particular. Right. So there were already applications that just compiled a pre existing C C code bases over to the web using asmjs and we wanted to be able to switch them over as soon as possible so that we can retire that technology and have something more forward facing. So the 1.0 release was totally targeted at low level languages like C C and Rust. And the feature set was really only you have this linear byte array as your memory model and you have the 4 basic numeric data types and that was all there was to it. Right. So not much more than that. You could define functions, could compute in terms of arithmetics and you had your memory and you had a way of emulating function pointers. So that was it, like very basic virtual CPU if you want.
- [06:52]
Kevin Ball
Yeah, well, and I remember hearing after that came out there was some amount, oh, this is super limited. And then people would like, hey look, I rewrote this intensive CPU intensive library that we used to do in JavaScript, I rewrote it in Rust or I rewrote it in C and now it's 30x faster. So these like stories of improvements now those may be isolated cases and actually that might be worth coming into if you have a JavaScript application. What types of benefits do you see compiling down to WebAssembly over JavaScript?
- [07:25]
Andreas Rosberg
Yeah, I mean that depends a lot on what your domain is and what kind of computation you're doing and how dynamic it is. So if you're really just doing low level numeric stuff and you can basically ahead of time compile all that to a very efficient code, then that's where WebAssembly really shines. Right. So you basically get next to native code performance if you have more complicated like language runtime things, especially in 1.0, like you need a garbage collector or anything like that. Right. Then you will have a much less pleasant time at that point because you have to emulate all that and you are fighting against some of the abstractions that WebAssembly imposes, mostly for portability and security reasons. So. Right. That's why for more high level languages, for example, WebAssembly 1.0 is not a particularly attractive compilation target. Also in terms of performance, again it depends A lot of what you're doing. So there are certainly things where JavaScript might even beat WebAssembly. The reason being that it's a way more dynamic system because it has to be anything close to fast. It does dynamic profiling, dynamic recompilation and really, really crazy things behind your back at runtime. Which of course all have a certain cost to them as well. Right. You're just not seeing that usually. But of course you can easily construct cases where this is creating much better runtime than WebAssembly ever could because it doesn't try to be as smart. Right. So this has been traditionally also fun thing with benchmarks because if you're not careful with benchmarks then JavaScript engines could easily optimize away half of your code that what you're trying to measure. And so yeah, yeah.
- [09:19]
Kevin Ball
I came up in the high performance computing world, you know, 20, 25 years ago and benchmarks were. And every compiler was trying to figure out okay, how can I game this benchmark? But in a way that's obvious that it's gamed.
- [09:31]
Andreas Rosberg
Yeah, that was like the time I was on the VA team like in the tens, mid tens, early mid tens, that the benchmark war was like all on. Right. It was completely ridiculous and I still feel a bit traumatized from that time and basically trust no benchmarks at home.
- [09:51]
Kevin Ball
Well and we're revisiting that now in the LLM era and everybody's trying to figure out benchmarks and they're not necessarily representative. Let's keep moving forward. So you mentioned. All right, 10 targeting very low level languages, languages that probably aren't having to deal with garbage collecting, aren't having to deal with these other things Moving forward then 2.0 was how many years later.
- [10:12]
Andreas Rosberg
Depending on what you. What you count. Right. So there are the proposals and when they are done and then there's this official process about like relev back, which in this case took years after everybody already shipped all the features in it. So technically I think it was released in 22. Practically it was more or less done in 2019 or something. Maybe 2020. I don't remember exactly. So that's when all the browsers implemented it and the features were completely done essentially. And the main big feature in 2.0 was the support for vector instructions. And that was again like take more advantage of like hardware capabilities, really compute intense stuff and allow them. Allow applications to take benefit of what modern hardware provides in that regard. Yeah, so that was a big feature. And then another somewhat. There were very smaller Features and one other interesting feature that was kind of showing a new direction was the addition of what we call reference types. So in addition to just these 4 numeric bit pattern types, you now have an opaque type of references. And that with two reasons at that point. One was to have more first class handling of function pointers, which we can't treat as transparent reference or transparent pointers. Right. Because that would be completely unsafe. So to have a way to pass them around, you have to have a type that keeps them, that ensures that you can't peek at their bit patterns or anything. And the other reference type, external reference, and that gave you a way to basically pass through host values. So on the web that would be JavaScript values through WebAssembly code. Right. You can't do anything with them, but you can hold them and round trip them. And that offered a much more convenient interop story with the web in particular, where previously you kind of had to maintain bijections on the boundary, that was like really ugly and brittle to do.
- [12:21]
Kevin Ball
Yeah, I do remember that being a big thing of, you know, if you were going to port something over to a webassembly for a library or whatever, like really having to be careful about what's the interface and keeping it as slim as possible because it was hard to move anything around.
- [12:35]
Andreas Rosberg
Right, right. So yeah, so external references at least in principle made that easier. But also these were kind of like the inroads to what followed later with garbage collections of a much richer system of reference types.
- [12:50]
Kevin Ball
Yeah, well, and it feels like in a lot of ways 3.0, which is what, what brings us together here was just a mammoth step forward in capabilities. I, I was reading somewhere that some of these things had been sort of in development for seven, eight years, which is just a, a mind blowing time frame for anyone in the tech industry. How much has changed in the last seven or eight years? So let's talk about the big release 3.0. What was in the box and, and what does it look like?
- [13:17]
Andreas Rosberg
So the biggest feature arguably is the addition of garbage collection. Right. So that's what I just mentioned with taking reference types to the next level. So you now have support for defining your own reference types and a memory layout for them and then the webassembly engine takes care of allocating and deallocating them. It's noteworthy though that we try to make sure. So this is, has been a somewhat controversial feature because it's like, okay, that is no longer just like abstracting the CPU feature. Right. It's a bit More high level. But we were very careful to kind of stay within the spirit of webassembly of being a low level language. And I always phrase it as low level as possible, but no lower. And so this is a very low level GC feature in the sense that all you get is essentially structs and arrays. You don't get any objects or anything like that built in like you would have in other VMs, like the Java VM or something. Right. So it's really low level what the types are doing. They describe to the engine what memory layout you want, but you still have to map all your runtime data structure from your language to that low level representation. Like you would do a native code. Right. The only difference being that you tell the engine to allocate this stuff for you or one particular deallocated. But the complexity there is that, yeah, this type descriptions, if you want to avoid a lot of runtime checks, then you need a more clever type system that always knows what it is you're referencing without having to do any casts or at least a minimum amount of casts. And that's where the type system then becomes significantly more complicated. So yeah, that was one big thing. Let me quickly look at the list.
- [15:13]
Kevin Ball
Actually before we go further on that. So since you're targeting not only languages with garbage collection, but still those original languages, is that opt in how does one interact with it?
- [15:26]
Andreas Rosberg
So it's basically completely separate from this linear byte array that you had before. You can still use that, you can use both together. You can completely ignore the instruction set, the part of the instruction set that deals with gc and then everything will be as before. Right. Like you just don't have to use it. And some people have been worried about this creating extra cost in the engine and actually no, because like in web engines in particular, all it's doing, it's giving you essentially access to the garbage collector that was already there for JavaScript. Right. So now you can allocate something in there from webassembly code and that's all that changes. They have one combined gc. So and that obviously was there before. So nothing, no extra cost there if you completely ignore this stuff. So yeah, completely separate memory area that does not overlap at all with the linear memories.
- [16:26]
Kevin Ball
Yeah, no, that I think that's key. It reminds me of like Rust has this principle of cost free abstractions, right? Like anytime they can implement something that doesn't have a runtime cost, great. In this case maybe it has a little bit of a runtime cost, but it's opt in. If you don't use it, it doesn't layer any cost to the other pieces.
- [16:42]
Andreas Rosberg
Exactly. And we also have that philosophy. I think C always had that philosophy. Or C, they always call it pay as you go or some. Or maybe that was somewhere else. But yeah, there are various names for that, and that's definitely a philosophy Webassembly is also following.
- [16:59]
Kevin Ball
Yeah, I was looking at the feature list just before this, so I can bring some of them. Another one that I saw that I'd love a little bit of a dive into. What it means is this concept of multiple memories.
- [17:09]
Andreas Rosberg
Right. So this is more actually a technicality because contrary to popular belief, you already were able to have multiple memories before. You just were not able to access multiple memories within a single module. But in Webassembly before, you could have multiple modules that talk to each other and each of them defines their own memory. That was totally okay. There was just this weird gap that you could not bring them together in a way that you can directly talk and move values between multiple memories. And that was both kind of like a performance cliff for some kind of things that want to do that. And it was also a gap in the design in terms of modularity. So there are these tools that are basically acting like a static linker. So they take a set of modules and merge them together in one bigger module. And that worked with everything except memories, because you could not have multiple memories in one module. Right. So in general, this would fail if more than one module defined one. And now that was one of the kind of intentional gaps we left in the initial Design of WebAssembly 1.0 and always were meant to fill later. And it was more like, okay, we need to get something out of the door quick, so let's defer that. And now we've added that. That was basically one of the last kind of intentional gaps that we left initially that we filled in now.
- [18:37]
Narrator
If you're using AI to code, ask yourself, are you building software or are you just playing prompt roulette? We know that unstructured prompting works at first, but eventually leads to AI slop and technical debt. Enter zenflow. Zenflow takes you from vibe coding to AI first engineering. It is the first AI orchestration layer that brings discipline to the chaos. It transforms freeform prompting into spec driven workflows and multi agent verification where agents actually cross check each other to prevent drift. You can even command a fleet of parallel agents to implement features and fix bugs simultaneously. We've seen teams accelerate delivery 2 times to 10 times. Stop gambling with prompts. Start orchestrating your AI. Turn raw speed into reliable production. Grade output at Zenflow. Free SC Daily listeners quick question. When things go wrong in production, do you know why? In minutes or hours? AppSignal is the application performance monitoring tool designed for developers who want clean, actionable insights without a huge observability bill. You get all the tools you need to fix issues before customers notice, like error tracking, performance monitoring, log management and more. AppSignal works for teams of all shapes and sizes from startups and side hustles to SMEs and enterprise and is especially great for teams that build with Ruby on rails, Elixir, Node JS and Python. Start your free 30 day trial and get get 10% off a yearly plan with code SCD10. Go to www.appsignal.comscd that's www.appsignal.com scd and use code SCD10. If you're an engineering leader, you know this cycle your team's focused on building product. But someone in ops needs a dashboard, marketing needs an admin panel, finance needs a custom workflow. The requests pile up, you can't get to them all. So people start building their own solutions, Shadow IT spreads and eventually you're the one stuck cleaning up tools that were built with duct tape and good intentions. Retool breaks that cycle. Their AI appgen platform gives teams a governed place to build the tools they need so everything stays secure and under your control. Someone could type build me a customer admin panel that manages accounts from postgres and they'd get a real production ready app with proper permissions built in. Your teams get unblocked and you don't inherit a pile of technical debt down the road. So if you're tired of being the cleanup crew for Shadow IT, head to retool.com sedaily and see how other engineering teams are democratizing app building without creating chaos. Because honestly we could all use a better way to handle internal tools. Sometimes you just need Retool it might.
- [21:32]
Kevin Ball
Actually be worth just from a design perspective because I think building a whole I guess in this way case compilation target a whole assembly level language that is pretty low level. Like that's a programming domain not many people have explored. Like what types of intentional gaps did you leave in that 1.0 and how did you think about that? What were the trade offs evaluated?
- [21:56]
Andreas Rosberg
There were three main gaps in terms of oh okay here we only allow one of these when really in general in the future we want to allow multiple of These. So the first thing was multiple values. So a function or instruction initially could only return one result. And that was kind of silly in terms of a stack machine and constraining. So we lifted that and that was already like in the original paper we published that already had that worked out. And then the other two were multiple tables and multiple memories. So multiple tables kind of sneaked in in 2.0 as part of the reference types extension. Because that meant that previously you only had function references, so you could just do everything with one table. But now you have multiple reference types and we use tables in a more general way. So you need tables of different type. Right. That naturally requires you to be able to define multiple ones. And then the multiple memories was the remaining one we added later. There has been talk about having multiple start functions, but that is not. You can easily work around that. But yeah, so these were kind of like gaps we left in there where all instruction set in binary format already kind of anticipated that we will add them. Other than that it was more like, okay, let's for now stick to the feature set of things that are already in asmjam. So we have to cover everything in there. And then also what is the. In the intersection of all common CPUs at that point. So that everything that has a one to one translation in terms of instruction mapping to actual hardware, that is an easy one. And I think we didn't leave that many gaps there. There are more gaps now with simd, for example, because SIMD is a much more much sadder story in terms of hardware support, where hardware vendors really can't get their shit together and agree on what the instructions are and what their corner cases are and what the feature matrixes matrices are. And there are like random gaps in there that I really personally hate, but where just one hardware would not allow an efficient mapping of this particular case. So we leave it out and maybe at some point we add that basically we always have this MVP concept, right? In a more general fashion, which is, okay, let's always start with something that makes sense and we already know we want to extend it later, but have something that works and that we can ship and people start using it and we get feedback and experience and have a clearer picture of where we should take it from there. So WebAssembly 1.0 as a whole was an MVP with garbage collection. Like what we added now is sort of the garbage collection mvp. There is a whole list of post MVP features that we have in mind that we might want to add at some point. But there that are not and totally essential. Right. You can get by without them. So this is more like the usual kind of thing we're doing where we kind of try to keep the broader picture in our head at least with have a rough idea how, how that could be integrated later, but focus on the things that we can solve quickly enough even though it still might take eight years. I don't know.
- [25:18]
Kevin Ball
Yeah, I'm curious actually. So one as you're getting that feedback from each version of mvp, which I think is that is the sort of approach that we all at least idealize as an approach it's not always easy to follow. Is that feedback from browser implementations? Is that feedback from compiler implementers? Like what were the different things that ended up shaping from 1.0 to 2.0 to 3.0?
- [25:44]
Andreas Rosberg
Yeah, it's often like sure, compiler writers, engine writers, framework writers. Sometimes it's CPU vendors that want to push their. Like this is a bit of what happened with simd. There was a very strong push from CPU vendors to have support for their ultra cool and fast feature. So at that point it might be somewhat political, but yeah, usually it's kind of for the bigger features. It's a broad understanding of okay, we have this low level language and there clearly are things we can't handle yet, but what would that mean in terms of a feature? And then we design these bigger features. So like GC was a discussion from the beginning. Exceptions is another thing that is in 3.0 now, right? Which also was in the making for very long. Threads is another one that although it's also already implemented everywhere and has been for years, the biggest gap now is still missing is something like some continuation like feature. Maybe we want to talk about that later. But this is always things like we know that there are some language features you can't compile currently because there's some functionality missing. That is one big thing. And usually as engine people and compiler people, we know what these things are and we already have plans to some degree for attacking these at some point. Modular priorities. And then sometimes there are smaller things that just come from clients, users, third party compiler writers that notice oh, you know, this is kind of a thing that would be good to have here because I can't do it easily the other way. And then they propose something as well. Yeah, like that. I mean this is a process. I don't know how aware people are. This is like completely out in the open. WebAssembly is totally like an open source project in a way and the committee is open for everybody. Right. So in, in theory, everybody can join there and propose a feature, but there is a very elaborate process you have to go through to push that feature over the edge. In the end, in particular, you have to convince the rest of the committee that it's worthwhile. But that happened a number of times.
- [27:59]
Kevin Ball
Well, actually I wanted to kind of ask, are there any features that have made it out in one of the 2.0 or 3.0 releases that you did not anticipate that were not sort of already in the back of your head of like, oh yeah, we'll want to do that eventually.
- [28:14]
Andreas Rosberg
So I think more of those are kind of landing now, now that we have gotten over the hump of the big features that we wanted to do from the beginning. Maybe one thing I didn't anticipate was this relaxed SIMD kind of extension that we have in 3.0 now, which is also, to be honest, not a feature I'm particularly happy about. That's a different story. But other than that, most of these are kind of. Yeah, have been in the making for a long time and always with a trajectory to them. I don't know when we started talking about 64 bit address spaces, but I'm pretty sure that also was from the beginning that eventually we will probably support larger address space. So yeah, it's a good question, but actually in the releases so far, there aren't that many features that were not kind of that came up much later, maybe just being a function of how long it takes to add a feature.
- [29:10]
Kevin Ball
Well, and, and in a lot of ways I think this is well, trodden ground in terms of supporting all of these different languages. And so you're kind of catching up to the cutting edge in a lot of ways. And then at some point you catch up to that frontier and then there's what pushes forward. Speaking of that, I think one of the things that I saw that I thought was interesting was 3o added tail calls as well, which I think is a very important functionality in terms of enabling efficient use of more functional languages. I'm curious, kind of, if you look at the spectrum of languages, what does support for compiling to webassembly look like now? Are there any languages that are not actually supporting this yet?
- [29:54]
Andreas Rosberg
Well, I mean, that's up to the languages, but I would think that most languages that have a certain user base have some form of support for webassembly at that point. And 3.0, especially with garbage collection, but also tail calls was an enabler for a whole new set of languages targeting it now, like functional languages like you mentioned, but also other GC languages like Java and C and they're using that instruction set as well. Yeah, I mean, there are so many languages out there that I don't have anything closer to a complete knowledge of who has a webassembly backend and who hasn't. But most of the languages that I come across, usually they already have it in some form with varying maturity of course. But yeah, it's very much a thing these days in your compiler ecosystem to at least consider it.
- [30:50]
Kevin Ball
So looking at that now and looking at how much easier it is to navigate across the JavaScript to webassembly border now with these new features that you have, this wide language support, can we revisit the question of when does it make sense to use a language targeting WebAssembly versus JavaScript or TypeScript? I think the calculus has probably changed a little bit since 1.0.
- [31:13]
Andreas Rosberg
Yeah, absolutely. Right. So more high level languages, especially GC languages, are much more reasonable to compile them to webassembly. Now I would think that actually it's reasonable for most applications. The only thing, if you're really building something that all what it's doing is DOM interaction and manipulating the dom, then you probably won't get much value out of it, right? Definitely not in terms of performance. It won't necessarily be slower either, but you might have to jump through extra hoops with all the glue code and so on and so forth, which is much quicker if you can just do it in JavaScript directly. So that is the main domain where I would say, okay, it's probably still better to use JavaScript or potentially if you're compiling a language that is very closely integrating with JavaScript by design. Right. Then that might also be better to still target JavaScript itself.
- [32:13]
Kevin Ball
So that's kind of actually an interesting thing to discuss. So when I think about building an application in JavaScript and particularly for the web, you have JavaScript the language, all the runtime and libraries, but you also have all of these web specific APIs that are available in JavaScript. Are those exposed directly in WebAssembly as well if you're building for the browser or do you have to hop over to JavaScript to access the API and then hop back?
- [32:37]
Andreas Rosberg
Yeah, yeah, that's a famous kind of question and complaint. Give me DOM access. Right. The thing is, yeah, right now you don't have that. And that is actually very important part of the whole webassembly security model that it's completely sandboxed, right? You have no ambient capabilities to have any access to your environment whatsoever. Anything you can do or interaction you have with your environment has to come through imports. And that's like Core to its very tight sandboxing functionality. So what you have though, is this very tight integration with JavaScript in the sense that a WebAssembly function you import can just be supplied as a JavaScript function, providing the kind of signatures match up sufficiently well. So basically you can just import JavaScript functions and then just call them as if they were webassembly functions. The problem, of course, is that all the web APIs are really totally design for JavaScript and they don't really make a lot of, or many of them don't make a lot of sense in terms of more moderate kind of object system language. So you usually end up having to write some or may have to do some glue code there. But this is more like a tooling problem. So people often make the assumption that it would be way faster if they could Access, say the DOM from WebAssembly directly. But that's not actually necessarily the case in particular, since JavaScript engines already go to way more lengths to optimize all sorts of things about accessing objects and JavaScript objects and DOM objects. And that would be ton and a megaton of stuff that you would have to replicate in the WebAssembly code generator. And I don't think anybody is willing to do that because it's kind of silly, right? You wouldn't even, probably not even get much performance out of that because the overhead of calling from WebAssembly into JavaScript is accurate, actually mostly dominated by the actual work done in the DOM itself, right? With most of these calls. So the assumption that it would be way faster something is not actually very accurate. That being said, there is some work now. So one thing you would like to have is at least have some kind of interfaces for accessing the dom, which people sort of agree upon. And that is something that is sort of a separate layer from WebAssembly Core itself, right? So people have now started looking into this in the context of this component model work. And so that might be something like maybe similar to these WESI libraries but for the web. So we start defining interfaces and they grow kind of organically and maybe at some point when they are mature enough, we have iterated enough on them, then we might even standardize some of that. But until then, it might just be a library or tool chain that just does this for you and you don't have to worry about it anymore because that's the other thing. Right. With the web API is a gigantic and B a moving target. So standardizing anything around that is kind of a challenge. Right.
- [35:59]
Kevin Ball
Like you, you were more generous than I was. I was going to say a fool's errand. Yeah.
- [36:04]
Andreas Rosberg
And. And you have to go through the, the pain of like trying to find a nice mapping to something that makes sense in Webassembly and possibly for more than just one language that wants to interface.
- [36:17]
Kevin Ball
That was the thing that I was going to to ask is, you know, now that you have relatively flexible, a relatively flexible type system, is there actually a substantial difference in terms of the interfaces per language? WebAssembly leaves a lot of that to the language compiler type. Yeah.
- [36:34]
Andreas Rosberg
So there's still no sort of automatic interoperability between languages. Right. And that is very intentional because that in practice never works because even the smallest impedance mismatches basically usually break everything. So it was very much an axiom in WebAssembly's design that we not try to, to solve this problem because it's essentially unsolvable, at least on that level. And trying to solve this is sort of what the component model tries to do. Right. That defines a somewhat more high level language agnostic type layer, which is more high level as well than GC types we have in Webassembly. Now, because I mentioned that these are very low level. Right. They don't know what an object is or anything like that. They just talk about low level representations really. So the component model has more high level types and they are particularly designed for multiple languages to be able to map to them and talk through these with each other. Right. And that would be the preferred way to also define maybe a Web API for WebAssembly. So on this level of type system that everybody knows already, at least if they want to implement against the component model, they already know how to talk to and have mapped to their language.
- [37:49]
Kevin Ball
Let's maybe step back a moment and describe the component model. So this is another webassembly spec or what exactly is it?
- [37:57]
Andreas Rosberg
So this is ongoing work still, and at some point it might be a different spec, but we're not quite there yet. So this is trying to define a separate layer on top of WebAssembly itself, which is like a more advanced module system, if you want. That's one view of it, plus a more high level language, agnostic type language to describe interfaces. Right. And with that you can basically specify how you bundle WebAssembly modules, you can define how they instantiate each other probably and things like that. And then there is this closely connected to that, this WESI effort, the WebAssembly Systems interface, which tries to define a whole set of, of kind of standard in air quotes interfaces with respect to this component model. So that like that are operating system abstractions, for example, so you can use them. And there are different ways to implement these interfaces. Either webassembly engine implements it natively so you have direct access to your host environment, or they could be virtualized in other ways. And the component model is pretty rich in allowing various ways of implementing interfaces and plugging things together for virtualization and stuff like that. But yeah, so that, that is ongoing work still. It's a very complicated problem to solve as you can imagine. And many people tried to solve that problem before and there have been various technologies that are, don't have the best reputation historically. I'm not much involved in that other than like talking to the people doing most of the work. But we are kind of very careful to not try to repeat the mistakes, have a more constrained system and take advantage of some of the inherent design advantages that WebAssembly has, like the strong sandboxing and all that. Right. And the strict portability. So it tries not to solve all the problems in the world at once. It makes some informed, opinionated choices, like when modules of different languages talk to each other, it's all like a shared nothing concurrency model. So you can't really pass pointers across the boundary because that introduces all sorts of extra problems. Right. That you want to avoid. That might also mean that it doesn't solve everybody's problem, but at least it solves a certain set of problems in that space. And from there we can maybe get more experience about other points in the space after that.
- [40:30]
Kevin Ball
Got it. So to sort of play back to make sure that I understand right now in the webassembly world, if you had different language implementations of different modules, there's no guarantee at all that they're going to be able to talk to that. That's basically on the developer to say here's the defined interface that you have to match and go. And so probably most people are making or developing these things as a, as a pluggable piece, either all built in one language or they're owning the whole system that's interacting. And what the component model, if I'm understanding correctly, is saying let's define a higher level interface that is true across languages so that you could build essentially libraries or modules that can interface with each other without having to know the whole system front to end.
- [41:13]
Andreas Rosberg
Yeah, I mean the situation with bare webassembly is kind of like with hardware, right? So you have your hardware types and that's it. And then if you want to have different compilers be able to talk to each other or to talk to an operating system or some other kind of environment, you need an abi. Right. An application binary interface. And that is something you can well define on top of webassembly. So far nobody has done that. Although like a few weeks ago when we had the last face to face meeting, there was actually talk about defining a C ABI for WebAssembly, which is the main one that everybody wants. Right. So you at least know how to talk to a CFFI or something. And that is standardized across multiple compilers and the component model you can view as an ABI on steroids if you want. Like because there's a kind of. It's not a fixed abi. You have a glue layer in between. You can define how you interface to that. But yeah, other than that, that's exactly what it is.
- [42:12]
Kevin Ball
Well, and this starts to, I think, take you out of the world of webassembly is a way to build singular web applications and into a world where you say, okay, webassembly might be a generalized operating system or virtual machine that you can target for different reasons. So let's maybe actually divert over here. We've talked a lot about web use cases for webassembly. What are some of the non web use cases that people are wanting to use this for?
- [42:40]
Andreas Rosberg
Oh, there are many web use cases at this point. Actually the web is just one among many at this point and which kind of we hoped for from the beginning and it worked out better than we expected. I mean we made very sure that the webassembly design and also the spec is not at all tied to the web or JavaScript for that matter. Right. And the web in the name was more like a marketing thing if you want. It's really intended to be like this, maybe bit hyperbole, but universal VM if you want. Right. And so what are the use cases? So people are using it for editing computing a lot. Right. Like Fastly is the biggest company doing that. They bet everything on webassembly. There lots of use cases in embedded space, which kind of confused me for a while because why would they take this overhead when they have small CPUs anyway? Well, turns out the big feature for them is portability. So we have People from Siemens, for example, in the working group who explain that, you know, we have all these embedded devices and there are new, new processors every year or month or whatever, and it's a pain in the ass every time you have to rebuild your entire toolchain. And now they don't want to do that anymore. They want to have a webassembly toolchain, then basically just switch out the back end for their CPU directly. Right. But they have this very different use case from the web because first of all they have much smaller systems, so they need a much leaner runtime, ideally like zero size if you want. And they also want to do ahead of time compilation. They don't want to do JIT compilation like you do on the web. Right. They have this whole tool chain, but in the end they compile to the actual hardware they want. And of course, WebAssembly was designed with AOT in mind as well. We always wanted that to be an option. So we also took a lot of care to not shut the door on that. And there are other kind of optimizers that take benefit of that. But yeah, actually seeing that happening for real is also interesting. There are more fancy use cases like in AI where you kind of use webassembly to control pruning in some search or whatever. So you make some things programmable, but in a portable way. Right. With a very universal language like you, you script your, your pruning algorithm that way. I think Microsoft did something like that. There are blockchains who use it as their execution platform and they're one of the features they are particularly interested in. Besides, like the sandboxing is the well defined deterministic semantics because if that's the code you execute on the blockchain, I mean, blockchain is whole hype word, right? But what matters there technically is you do replicated computation and then you rely on consensus between the different replica to deliver the same result. And of course that won't fly if you have under defined, under specified behavior all over the place, because then everybody will disagree all the time, right? Like, and webassembly is to a large extent fully specified and fully deterministic. And with 3.0, we even have a deterministic profile now which is kind of of specifying. If you really want to be fully deterministic, this is what it means. So everybody has a clear picture of what that means and can depend on that. So you always get the same result.
- [46:13]
Kevin Ball
So let me, let me actually dig in a little bit on this because I think Naively, I tend to think of most traditional programming environments as being deterministic as contrasted to. Now we do all this stuff with machine learning and LLMs, and that's where I think of, oh, that's non deterministic.
- [46:29]
Andreas Rosberg
Explain here that deterministic is used here in more like a abstract way. So we say that a language semantics is non deterministic if it is maybe specified, but allows multiple different behaviors, and then any particular execution or any particular implementation can pick one of these. But the point being, if you run on different hardware or maybe under different hardware constraints, right. Then you could get these different, different behaviors, right? And that's what you don't want. So the way you model that semantically is usually as non determinism. So just you get a random pick of the allowed people.
- [47:08]
Kevin Ball
Got it, got it, got it. So this is places where essentially the language spec does not fully pin everything down. And so different implementations of that on hardware or just different compilers or whatever can make different choices. And so it may be deterministic within a single environment, but across environments it's non deterministic.
- [47:24]
Andreas Rosberg
Yeah, and even within a single one it sometimes might not be. You never really know. So There was WebAssembly 1.0 was very neat in that regard. There was only one little source of non determinism, which was with floating point arithmetics. So if they generate nands, then unfortunately the IEEE standard for floats fail to define what the bit patterns are for nans, and all the hardware vendors completely disagree on what they do and even how they interpret these. So there are funny things like IEEE defining a, a quiet bit or a signaling bit on nands, but it doesn't define what way it's to be interpreted whether one is signaling or zero. And surely hardware disagrees on that choice, right? So silly things like that, and initially we try to even lock that down and say, okay, if your hardware's behavior diverges from what we specify, you have to normalize all your nands. But turns out that is very expensive. You don't really want to pay the cost because then all float computations get more expensive. Although that's what, for example, blockchain implementations do. Exactly, right? They do that. It's not that bad, but you pay a certain price for that, right? So that is the kind of thing why we have non determinism on the spec level. Of course, you also have natural non determinism once you start talking about things like throw threats. Right, because that's essential in the concurrency model that you have non determinism that is more like intentional non determinism that's really core to what the feature is about. But all the other are sort of like accidental non determinisms that are just really under specifications because we can't do better and the less we have of that, the better.
- [49:10]
Kevin Ball
Yeah, well, and this is sort of a level of care or if you're on the other side, like, like pedanticism that most developers never have to worry about. But if you're a language designer, all the way down. Okay, so we talked about some of those use cases. We talked about how so hardware embedded folks might be doing this to simplify their tool chain. Blockchain. You talked about determinism. What are some of the other drivers for non web use cases to adopt webassembly as their target?
- [49:37]
Andreas Rosberg
I think it's usually two things. One is portability and the other is the sandboxing model. And of course the fact that it's pretty universal as well. Right. So it's like Turing complete. You can compile everything into it. It's not constrained in any particular way. So those are the three reasons why it's a good fit for various places where you want to kind of embed some form of compute without tying yourself to whatever, like a specific scripting language or open security holds or whatever. Right. So that's kind of how you make use of it. Yeah. And it's also fast, which sometimes is a bonus as well.
- [50:15]
Kevin Ball
Yeah. So I think the, the example that comes to mind for the closest to that sort of universal virtual machine model that anyone's come before, I think, is the JVM and all the different JVM targeting languages. What are the factors that might cause somebody to move from a JVM environment to a webassembly environment? Are they exactly what we just said? Is there some other nuance we're missing?
- [50:37]
Andreas Rosberg
Yeah, I mean, the JVM is interesting because that is really a VM that was designed for Java. Right. And it has all. It's basically an abstract syntax for Java, if you want. So it has all the Java object model built in, which is pretty heavyweight, including all the reflection stuff and so on. And there are other things it doesn't have built in. Right. You can't do so when you compile to jvm. And many languages have done that. Usually if you don't happen to be like very much exactly like Java, then it's not going to be very fast. There are things like. So for example, with the GC extension, now one thing we have that other VMs don't have is we have tagged pointers. So I don't know if you know what tagged pointers are, but if you have a garbage collection runtime, then usually the garbage collector has to know what a pointer is. And sometimes you want to unbox integers so that you don't have to put everything into a box and allocate. So you usually use pointer tagging, which is you take a bit off every pointer that marks it as an integer and then you can just use an integer as if it was a pointer. And the GC knows about this bit and just follows the real points. And that's something we actually provide directly as a webassembly feature, Whereas in other VMs you don't have that. But there are many language runtimes that make heavy use of such a feature to like avoid boxing all their small types. Right? And yeah, do things like polymorphism much more efficiently. And you pay in with, with the jvm you, yeah, you pay the price for the heavyweight object model. So if you're compiling a language that for example, example has lots of very small allocations, which is for example the characteristics of many functional language, then that would not be ideal for you because your characteristics run again against what it's optimized for. And then there are other things like I don't know if you want to do closures and stuff that's also very costly in the JVM because it's not like native to it and, and you have to encode it in heavyweight ways and all these things. Right. Like you don't have access to the low level as much as you have in webassembly, so you have to jump through more hoops in a way.
- [52:58]
Kevin Ball
So let's now look forward a little bit. What does the next generation in webassembly look like? What can't webassembly do? Well right now we mentioned a little bit the component model and that is as a big area of, of exploration and focus. You also sort of had a throwaway comment about continuations. Maybe we can dive into that. But yeah, what's coming down the road?
- [53:21]
Andreas Rosberg
Right, so in terms of bigger features, I mean there are various small features in the making, but the two big features I would say that are still missing from core webassembly. So not the component model is threads is the one which is sort of on the finish, close to the finishing line finally I hope. And the other is what used to be known as stack switching or which turns out we model it as this form of delimited continuations. And the reason this feature is important because this is what allows you to compile at least efficiently all these control abstractions that modern languages have. And control abstractions are things like, I don't know, async, sync, await generators, green threads, you name it, right? All these things where you have non local control flow, and usually these are implemented, or often they are implemented in some way or the other by having multiple stacks that you switch between. And when you are in a system like webassembly where you have to be type safe and where also the actual stacks are kind of encapsulated, you can't really get to them for safety, security reasons. Then it turns out that there is a neat abstraction that is already well known in the programming language field for decades, which are continuations or delimited continuations. So that is kind of like how we model them. So you have a way of basically continuation is a new stack, if you want, you have a way of creating a new one and then you can resume their computation there, which basically sort of switches over to that stack and then that computation can suspend, which switches you back to the point where you resumed, very roughly speaking. And you can have as many of those as you want.
- [55:08]
Kevin Ball
So I assume that since those control flow features that you mentioned are in a number of languages, including some that I believe already target webassembly, how are they supported today? What will this take you forward to?
- [55:22]
Andreas Rosberg
There are many kind of ways you do that. So the most powerful way where you can do all that is you do a global program transformation called cps. So continuation passing style, where for every function you have an additional parameter which tells it where to continue instead of returning. That is also a well known technique, but you can imagine that is pretty expensive. So some languages actually do that, others use tricks by, I don't know, trampolining through JavaScript, for example. That is by the way also how C implemented exceptions before WebAssembly 3.0, right? It had to call into JavaScript to create an exception handler, then call back into WebAssembly to actually run its body, and so on and so forth, which is also kind of crazy. And of course it only works when you have JavaScript. That's one technique. Yeah. So once you have exceptions you can do trampolining, which is you just build up your call stack and eventually you throw back to a scheduler that then somehow has an idea of how to build up the call stack again if it has to. And there are various techniques like that. They all have in common that they tend to be brittle and costly to some extent and not very modular. So one of the features our proposal has, which is something that came out of academia in the last kind of 15, 20 years, it's based on this idea of effect handlers, which is essentially the simplest way to understand, is a generalization of exception handlers that allow you to resume at the point where you threw, but you can resume at any later time. And the thing, the continuation is essentially your object that allows you to resume. What effect handlers give you, as opposed to these other techniques, is that you can compose these handlers in a nice way and without them interfering with each other. Whereas if you have to manually do these transformations and you have more than one of these control effects in your language, then you have to do all of them kind of together. With effect handlers, you can do them in modular ways, separate from each other. They don't have to know much about each other. You can just suspend over another handler essentially. And that is very nice. For example, if you want to do both threads, so green threads, virtual threads, and say async, Await or generators, then one is in a much smaller scope. But you still want to be able to suspend the entire thread that runs the generator by directly going to the outer one without the generator logic having to know anything about that.
- [58:06]
Kevin Ball
I think it's really interesting. We've had a number of conversations with different folks about kind of advances in the programming language world. And like we have these new, newer languages that are building on these capabilities that have really just happened in the last 10, 15 years, if you look forward even further. So that's what's on the horizon now where what else is in the back of your head of we're going to want to get there eventually we're going to need to get there. What you want to enable with webassembly?
- [58:37]
Andreas Rosberg
Well, yeah, I mean, we already got quite far as far as I'm concerned. So one thing I would like to see is WebAssembly having more built in support, like in standard operating systems, for example. So it's in every browser. But why does, I don't know, macOS or Linux or Windows not support it out of the box, right? So that you can actually run just desktop applications using WebAssembly so it becomes even more of a portable format. And the extreme point of that would be to put it into hardware. So I keep hearing people talking about that and considering the ideas so far, as far as I'm aware, nobody has actually tried to do that for real, and there are some hurdles you have to get over, but in principle it should be possible. And that might also be very interesting because it's a virtual CPU ultimately and at least some feature subset of it should be possible to, to implement more or less directly in hardware.
- [59:38]
Kevin Ball
So what you're saying is the next ARM spec or something like that is directly targeting webassembly?
- [59:45]
Andreas Rosberg
Well, not the ARM spec, but there might be a WASM processor, a WASM CPU of kinds, or maybe a custom chip or whatever or FPGA or something that people who want to run that in certain environments can take advantage of. I don't know, something like that.
- [60:03]
Kevin Ball
Love it. Well, we're coming close to the end of our time here. Is there anything we haven't talked about yet that you think would be good to leave our listeners with?
- [60:12]
Andreas Rosberg
Yeah, I mean, one thing I could briefly mention is because I'm heavily involved with that side is the specification side of things with Webassembly. So one thing we're particularly proud of is that not just don't we have undefined behavior at all, right? We have everything formally mathematically specified and verified. So we have machine verified proofs that we don't have undefined behavior. And there's a lot of work going into that and extending the kind of infrastructure for that now with various research teams that hook it up to various theorem provers to do even more fancy things of theorem proving, reasoning about programs and, and things like that, which I think is a whole new level for an industrial programming language that nobody has done before either. So that's something I'm particularly interested in as well because that ties back to my academic self, half of myself that, that likes that stuff too. But I think it's very valuable. And I mean the, the, the reason that WebAssembly has such a clean and fairly safe design is this because we designed, or one of the reasons, at least I would claim, is that we designed with formalization hand in hand, right? We didn't just, you know, build this artifact and then try to make sense of it after the fact. We really did it at the same time. And that's when you kind of have to be honest with yourself when you're designing something and you have to formalize it and the formalization becomes hard and probably the design isn't quite right. So it's a nice feedback loop in the similar way that implementation is a nice feedback loop. You want to do all these things in parallel and feedback into the design. So both for semantics and performance and These things which I would love people to explore more also for other languages and that would give us also the. The other nice thing about that is that this gives a way of actually doing verification in depth. Depth, right. So because we now have verified hardware, we have a verified engine like webassembly and maybe we can now build more verified compilers and then you can actually verify the entire software stack at some point. I would love to see that kind of thing because frankly the state of the art with our kind of craft is still like leaves things to be desired.
- [62:36]
Kevin Ball
And not to be too much on the bubble area, but if we're using non deterministic machines to generate code, which is what more and more people are doing with LLM based programming, having a way to deterministically validate and verify it after the fact is going to be ever more important.
- [62:55]
Andreas Rosberg
Right? Yeah, absolutely, yeah. The more code we let be generated by dubious sources.
- [63:04]
Kevin Ball
I mean, humans are pretty dubious as well. I've read a lot of human written code that, that, that feels pretty dubious to me.
- [63:12]
Andreas Rosberg
Fair enough. Yeah. Yeah. But for, for some reason people are less willing to trust humans when writing code than they are willing to trust AI when it's writing code. There was just a study coming out I just read about today that is a bit scary. So when you, when you're pair programming with the human partner, then you usually question everything he's doing. When you do that with an AI, not so much. Although it's at least as failable.
- [63:39]
Kevin Ball
Formal validation of the outputs.
- [63:41]
Andreas Rosberg
Yeah, definitely would be nice, but that's very much an open research area as well because it's a very hard problem in general. Awesome.
- [63:50]
Kevin Ball
Well, thank you and let's wrap.
- [63:53]
Andreas Rosberg
Thank you very much.