WASM 3.0 with Andreas Rossberg
===

Noel: [00:00:00] Hello and welcome to Pod Rocket Web Development Podcast, brought to you by Log Rocket. Log. Rocket provides AI first session, replay, and analytics, which surface the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it free@logrocket.com.

I'm Noel, and today we have Andreas Rossberg, uh, programming language researcher, designer and engineer. We're here to talk about web assembly three. How's it going, Andreas?

Andreas: It's going good. Thank you. Thanks for having me.

Noel: Of course, of course. Um, I feel like I always want to, uh, kind of frame this a little bit, ~um, just 'cause I think like web assembly is a thing a lot of people are kind of aware of and like, know it's there and there's some cool stuff.~

~Maybe they've used some projects that have had some notes on it in a previous release and, and you know, why it's empowering. Um, what, like, ~why was WebAssembly two a leap forward? And then what does Web Assembly three kind of bring on top of that?

Andreas: ~So, yeah,~ web assembly two. The, the primary thing it brought to the table was vector instructions. So sym instructions, which. Are sort of a niche thing, but where they are useful, they're very useful, right? Like, so you can really, uh, make decoders faster, [00:01:00] like video or other things or encryption stuff. But, uh, web assembly three is a much bigger, um, release in many ways.

It, it's a combination of many things. We have worked on various features over. I don't know, some since the beginning actually. So six or eight years. And that is more intended to kind of bring things to the table that allows a wider range of languages to target this, uh, as a compilation target. And

Noel: Yep.

Andreas: the biggest one there is probably garbage collection, right?

So for all these managed languages out there that is. Uh, a bit of an enabler. I mean, technically in principle you could do it before compile your own garbage collector, but there are some difficulties with that

Noel: it's a lot of work. Yeah.

Andreas: It's a lot of work and it, it's kind of like the kind of thing which works against the sort of safety abstractions that web assembly [00:02:00] has. So you also pay some overhead. Uh, so it's never gonna be competitively fast. And now we are making that a built in feature and probably the other. And, and then there are some other kind of things like exception handling you couldn't really do before. Tail calls is important for some languages. ~Um, and.~

Noel: ~Yeah.~

Andreas: Then probably the other interesting one, which is goes a bit of a different direction, is that we increase the address space to 64 bits. So that's again, an enabler for, I don't know, applications that need way more memory. ~Right? Like,~

Noel: ~right.~

Andreas: ~um,~ like big databases or whatever the so-called AI stuff.

Noel: Right, right, right, right. ~Yeah. You rattled, you rattled off quite a bit there. Uh, let's kind of, let's,~ let's talk about, ~um, yeah, like~ garbage collection and like type references and stuff a little bit. First, I guess you noted that now ~this is,~ this has enabled, ~um, web like~ WebAssembly to be a target, uh, for all these.

~Higher,~ higher level languages. ~Why?~ Why is this important? ~Like why, like why,~ why is that helpful for either like end users or developers?

Andreas: ~Yeah, so I mean it,~ it, it gives them more choice and it supports more [00:03:00] diversity on the platform, right? So it was actually always our goal from the beginning to make web assembly, kind of like the sort of universal compilation target, not being language specific at all. That is something I particularly value very high.

Others too. And it's kind of what the mission statement of WebAssembly try to be. Universal language, independent platform. Independent. So we want, ultimately, we would like to support every language out there, um, being. At least workable on this platform. And there's kind of like, there always was this like long-term roadmap, if you want, from the very beginning, kind of like the first release of WebAssembly specifically aimed at, at low level languages because they were already present, uh, on the web.

They were using A-S-M-J-S at the time or, or nle. And we wanted to replace those with. Something better. So there were customers already, right? So that could use that and they are kind of an easy target. So the first version of web semi [00:04:00] targeted those and then the longer roadmap was, okay, more, better support for more high level languages.

And then maybe at some point in the future we are not there yet, better support for dynamic languages as well. Right? Um, so those are kind of like the three tiers if you want, for supporting the universal and zoo of languages out there. And we are somewhat. No.

Noel: Yeah, yeah. No, it is, it is exciting. Are you guys expecting, like a pretty major? ~Um, I don't, I don't, I'm kind of, I struggle, I struggle with terminology here, but just, uh, an~ uptick of like, you know, developer code that ends up eventually getting compiled to web assembly now. Like, do, do you think that this will be a big kind of step forward in, uh, adoption of.

Web assembly as just ~a, you know, ~a target that people are actually using.

Andreas: ~I, ~I think it, it's more like, it will not be like a steep increase all of a sudden or something because all these things take time, right? People have to build like the ecosystems and the infrastructure and, and all that. But we already have, uh, half a [00:05:00] dozen at least of languages that target this new platform, like at this point, and.

I don't think they, they will, like, they will be immediately as many as they were in the beginning of WebAssembly with all the preexisting code that could just switch over. Um, but we definitely hope that it, it enables gradually more, more languages to run on this. And there's that more choices, as I said, both on the web and and outside the web, right?

Where web person certainly is also increasingly used.

Noel: Yeah. Yeah, I know. I, I always get my, I get my tunnel vision a little bit, and I'm always just, I'm always thinking about web use here and then, then some, some, some other edge cases stuff, you know, like functions and workers, but like, yeah.

Andreas: think about the.

Noel: Yeah. Yeah, that's probably, it's probably good. Good. You have that perspective. Uh, yeah. But like, you know, I think, I think everyone else kind of tends to fall into this trap. Um, is that, like when you [00:06:00] mentioned, um, like larger, uh, the larger. Address space earlier. And that's, that's probably like a good example there is, it's like for the web cases, that's probably not as big an ask, but I imagine there's a lot of non-web cases where it's like, we need a larger address space.

Were there any particular use cases that, um, you know, like you guys really felt the need to get the, the, uh, 64 that address space on the table for.

Andreas: So first of all, on the web there are these additional limits that kind of the js uh, embedding imposes. So on the web you will still be limited to 16 gigabytes of memory. Um, but outside the web there is no limit other than other platforms kind of imposing it. And yeah, there, there have been users. So like one is, um.

A company I worked on, they, they use WebAssembly in some kind of like distributed computation blockchain if you want context [00:07:00] where you can allow applications to do a lot of data and basically have in-memory databases. And they were always struggling with the Fear four gigabyte, uh, limit and already worked around it before for years, but now it's much easier for them.

I mentioned like large language models as well, right. So, uh, there are people who want to do that on web assembly because of portability or I don't know, safety for various reasons, right. And then, yeah, uh, easily run over that as well, and. I don't actually know who else. Um, but I only know in the background that there have been lots of requests to lift this and lots of complaints that, oh, I only have four geeks.

That is, that's not enough.

Noel: Yeah. Yeah, there's a lot. I mean, there are a lot of use cases like that. Portability is an interesting, an interesting use case, and this is, I feel like kinda something that's always talked about a little bit when we're talking about [00:08:00] these kind of more agnostic. Targets, right? Like, or more Agnos agnostic platforms and like the ease of developers running, running stuff locally or the capacity to distribute.

What, is there anything in particular you think that makes WebAssembly, um, like a uniquely good fit there compared to other technology that we've kind of tried to push through historically?

Andreas: Yeah, I mean, of course we, we learned from the problems that the previous technologies had, like, I guess the particular ones, uh, the Java, the JVM and, and the net platform, right? So they were. Specifically designed to support like one language very well. Right. And in both cases there are tons of other languages that sort of compile to them, but they pay us pay quite a price to work around the impedance mismatches.

And that's definitely one, one thing we wanted to avoid, right? Like I said earlier, we want to be a unbiased universal platform. [00:09:00] And the, the key to that is that WebAssembly is more low level than the other platforms in, in. In terms of its instruction set and o object model, if you even want to call it that, because there are actually no object.

Um, and yeah, so that is one thing. The other thing is that, um, we also built like sandboxing as part of the module system That web assembly is, is based on in as, as a very fundamental technology, right? So. Every WebAssembly binary is a so-called module and it has imports and exports, and that's all there is.

And a module itself can't really do anything. It's completely sandboxed. The only way it has access to its environment is through the imports. You give it and you have to provide those explicitly. So it's kind of like a capability based, uh, security model if you want. And that makes it interesting for various people who are concerned [00:10:00] about security and.

Uh, application code, grabbing some ambient capabilities and just accessing something. So this is a very tight model in a way that is very simple, but like has been there from like, not as an afterthought, but as a basic model for WebAssembly and people like that too. Two.

Noel: ~yeah. Yeah. It's, it, it's an interesting kind of setup and I, it's not, I am, I'm at the, the limits of my, uh, like, experience here. Um, but like, it makes me,~ it makes me curious,~ like if there's, if there's a, if it,~ if it significantly reduces ~kind of the, uh, you know,~ the. Exposure area for a lot of, ~you know,~ use cases or ~like, is there,~ is there any fear I guess of the, like, you know, one is one's using a high level package and that thing ends up passing file system in and then it like needs for some package, it has four dependencies deep or something like that thing being the problem.

Is there any kind of traceability on like, you know, wind going and finding a tool to pull off the shelf? Like where this thing actually is sending these, uh, like, um.

Andreas: Um, well, you

Noel: in its tree.

Andreas: you, you could certainly, uh, implement static [00:11:00] analysis tools that try to figure out these kind of graphs and dependencies more easily in web assembly, I guess, than maybe in other languages. Um.

Noel: It would be direct, like you could, you could be pretty, it'd be pretty easy to kinda trace those lines, I would

Andreas: Yeah, it's a bit less easy once you talk about, uh, function pointers, function references, uh, really because they are more first class, so that in general requires some more advanced analysis, right? Or tables.

Noel: Sure.

Andreas: Are sort of midway there, there's this table primitive, which allows you to store an array of these function references.

So if you share that table, you also share the references in it. Um,

Noel: Yeah.

Andreas: but yeah, I mean, any, any such static analysis will have its limitations. But, um, if you're following certain disciplines, it can do, probably do a very good analysis on, on regular code. Um.

Noel: Right, right. It's, no, it is no worse than any other, and it's kind of, kind of a necessary [00:12:00] evil.

Andreas: not. Like again, somebody, yeah, somebody you have to give it, give your reference to the code somehow, and then someone has to pass it on. But yeah.

Noel: ~Yeah. Um. The, does it, does this play into, uh, like any of the other, I guess were,~ were there any features in, in 3.0 that ~kind of are, uh, like, ~we're focused on this? Or, ~or, or particularly, um, you know, like~ more easily leveraged on kind of this like import the module ecosystem or is that, was that stuff pretty settled as historically?

Andreas: ~so yeah.~ Interesting question. So one thing that might be related to, to the modularity aspect, aspect is the, the ability to have multiple memories,

Noel: Hmm. Okay.

Andreas: right? So this is really in a way just closing a gap that we had in web assembly before where contrary to popular belief, you could have applications with, with multiple memories.

Um, except that a single module could never reference more than one,

Noel: Ah.

Andreas: right? So. And that was a bit artificial because it meant that certain things are not possible. Like one tool that people try, uh, use. [00:13:00] Routinely is merging modules, smaller modules into bigger one. And that worked in all cases, except if they both had a memory, then you couldn't build the bigger module from those.

But, um, with terms, uh, with respect to security, there's also an interesting, uh, feature because you could use it to separate, like shared public memory from your own encapsulated private memory. At least in principle, I mean, I'm, I don't know if that has been really applied yet, uh, in practice because some of the tooling there is a bit in the way.

Like if you compile through something like LLVM, then it's currently very hard to use this feature

'cause it doesn't really have support for, you know, separate address spaces.

Noel: Right, right.

Andreas: Um, so this would be more something that, uh, kind of like a primitive library can use internally so that you don't see it in the APIs or something, but it's definitely something that some security folks have been interested in.[00:14:00] 

And it's also a good use case for, or a good mechanism for, I don't know, doing something on the side. Like when you instrument your code, like, I don't know, you wanna instrument it with some kind of logging.

Noel: Yeah. Yeah.

Andreas: And you do that and put that into memory and you don't want to interfere with a code that actually is there, or other codes that you share the your memory with.

So you use a site memory log into that without affecting any of the other memory usages. Right. It's just completely separate. So in a way it's, yeah, modular or safer if you want

less interference.

Noel: yeah. Yeah. Less, less interference. That's a good, a good term. It does, it does kind of bring up this interesting, um, uh, what's, I don't know, I don't know a great term, but maybe like a, a spectrum, because this seems like something that would be difficult to leverage depending on, you know, like what language you are using or end languages as a developer and like, I.

I have a hunch this is something you guys [00:15:00] think about a lot and I'm curious if you have any thoughts on the like features being added to WebAssembly that may or may not be, uh. Like leverageable usable by a given, a given, you know, higher level language and like how that exposes it. Is there, is there any, do you kind of maintain a mental model at all of like, okay, this is something that will more, you know, be more leveraged by, you know, like a, a very large subset of the languages which we're trying to set up web assembly as a target for, versus like, this is only gonna be like one or two of the lower level kind of candidates able to use it.

Andreas: Yeah, I mean we usually try not to put in features that are too specialized to certain languages or language families, even if they're very mainstream. So in principle, I would think that all the features are use useful for a sufficient sufficiently large set of of languages. But then there are these, some features and maybe [00:16:00] multiple memories is one of them that are less target ads.

Being used by a language on top, but more by tool chains in the middle, right? They could do something with that, like the instrumentation I talked about, which it would not be visible in the source language. It would be more something that the tooling itself can use to play tricks.

Noel: ~Yeah.~

Andreas: ~Um.~

Noel: ~Yeah. You, you, you,~ you have some other module in the middle or there's some like compilation step or something that does this instrumentation layer or it's part of your

Andreas: things like that, or some low level libraries that you build that are sort of bindings and do some magic under the, under the hood, um, that are also not expressed in the source language, but more by the compilation pipeline or whatever. There, there are various things you could imagine happening there.

So, yeah. And I guess that is. Malt memory in particular is in that category. Trying to think if there are other features that are similar to that. I can't really think of many.

Noel: Yeah, at least nothing in the notes here ~that, that seem,~ that seemed quite that way. ~Maybe, ~[00:17:00] maybe like, uh, tail calls. ~But I would,~ I would think that would mainly be up to like the uh, um, implementers, like of the kind of

Andreas: Yeah, so tail cults are, um, so for certain source languages, they're essential, more or less, right? Like especially functional languages. But there's a very famous paper by Mattias who argues that if you want to do. Pure object oriented programming. You also actually need tail codes, otherwise it will not work.

Noel: Mm. Yeah.

Andreas: But so that is one use case there. It's not like necessarily like an explicit feature in the source language, in the sense that there's some construct that maps to it, but that every call in a tail position has certain. Guarantee that it can't overflow the stack, and that is one use case for it. The other is internally, again, in more like runtime systems.

Actually people use it a lot, especially when you have complicated engines like a JavaScript engine itself for example, uses a [00:18:00] lot of take calling internally to do all these like inline caches and stubs. It jumps into that. Then jump to something else and replace themselves with something else. You do a lot of that with take calling so that you can like creasing grow the stack.

So that's all like hidden away from the user. They don't really care, have to care about it, but it. Enabling these, these techniques. Um, but I'm trying like one other feature that is not new, but you could argue is also more for like, really the tooling or the compilation pipeline is, is actually tables.

Right? Tables not something you would typically expose in the programming language. It's, it's a feature to enable certain compilation techniques.

Noel: ~right. Yeah. Yeah. I'm trying. You're right, you're right. ~Yeah. It's kind of, it's kind of ~in that same,~ in that same band ~may maybe just for, uh. I could try here, but I'd rather, I'd rather hear you do it. Can you,~ can you explain a little bit to end users, again, who probably aren't ~writing,~ writing this stuff themselves, relying on something, what are tables and why do those, why do

Andreas: Yeah, so

Noel: help optimize?

Andreas: are, um. So another thing that people sometimes believe which is not true [00:19:00] is that, okay, web assembly has memory and that's all there is to it, right? To to stay. That that's not actually true. There, there are two other things. One is Globals, which are sort of what you think they are, and then there's more weird thing, which are tables.

And with web assembly three oh tables got a bit more general. And basically there are a way to store references. In some way that allows you to index them with numbers,

Noel: Hmm.

Andreas: any kind of references. So originally it was just function references and that was put in because that was the only way to basically imitate something like C function pointers.

Noel: Gotcha. Yep.

Andreas: So they provide an address space for, for code if you want, through this extra indirection through a table because one thing we don't want to do for security is we don't want to, uh, expose code addresses, obviously.

Noel: Yeah.

Andreas: Then how do you do pointers, uh, that you wanna store in memory [00:20:00] where they are exposed, right?

As some numeric thing. So you still want to have some numeric thing, and the way it works in web assembly is, well, you store a table index and then you do the indirection through that table, and that is bounce checked. But all you see is that index. You don't see a code address, so it can't be. Abused for any kind of like attack, uh, security relevant attack, and with web assembly three oh.

That is sort of generalized, that you can also use it for other kinds of references if needed. So basically the, the memory is the storage for numeric data, which is completely

transparent. And the table is a storage for reference data and references are completely opaque. You cannot observe their representation, their bit pattern for security reasons, right?

So you cannot store a reference in memory whenever you need a reference. Or need to kind of in like hold a reference. In memo, you have to go through this table in direction so that you turn it [00:21:00] into an index. So that, but that's very much like, uh, a mechanism that a compiler will use internally then exposing it to the source language user, right?

Or the

Noel: ~Right. Yeah. Yeah. Was this, is this did like the, did the,~ did the language implementers ~did, like, were, were,~ were tables kind of a natural. Abstraction there for most of 'em, or ~is that, is that, ~is that something that they even have to worry about that much?

Andreas: ~Um, so the,~ I mean the, the idea of using tables to implement function pointers that originates from A-S-M-J-S that already used this kind of approach to compile c and that way it was clear to us we needed something equivalent and. That was tables was just the easiest. So they were using array, but tables are sort of like a slightly more static version of that.

Noel: Gotcha.

Andreas: Um, so it was very natural to, to have that,

Noel: Cool. ~Yeah. Let's, uh, I don't, I don't wanna run too long here. So let's, let's kind of, let's get through some of the other, other stuff here. Um, let's talk about, uh,~ I wanna talk about, uh, like the deterministic profiles and exception handling. Which one of those do you think would be more interesting to jump into first?

Andreas: um. Yeah, I guess exception handling is definitely more interesting to, to [00:22:00] users, I

Noel: To more people. Yeah. Yeah. What, I guess kind of again, set the, set the stage a little bit here. Like where, where were we at before and what does, what does three three add?

Andreas: Right. So exception handlings, like GC was one of the features that was really in the making for many, many years, and exception handling originally was put in or desired or proposed. Because that was the one thing from c plus plus that we could not express. So the c plus plus compilation pipeline, when you actually turned on exceptions.

Which almost nobody does in practice, but there are some, there's at least one major company that does that, and that was, they were pushing very hard. So previously that was compiled by, basically, when you have an exception handler in c plus plus, it would be compiled to, oh. I'm calling out a Java script, JavaScript installs an exception.

Then I'm calling back into web assembly,

Noel: Yeah.

Andreas: [00:23:00] right? So it would ping pong across the boundary just to set that up, which you can imagine is like neither efficient nor very robust. And yeah, so there was the desire to have a mechanism built in that allows you to compile these things. And other languages obviously want that too, because exception handling is pretty common these days in modern languages.

Noel: Yeah. Is that, is it mainly a performance, uh, like a performance increase and for like end users, for developers? Is that kinda the big thing? Or was there not much exception handling support happening at all prior to this?

Andreas: Yeah. Prior to this you had to do this gymnastics to, to make it work, right. And um. I think for low level languages, as I said, c plus plus, they're not used very much. So that was sort of okay for many, but it was definitely a, a roadblock for other languages, more high level languages wanting to compile because they use exceptions.

And then, yeah, [00:24:00] they would also have to do this game somehow. There are various ways to do that. You could also do a, like a whole program transformation

Noel: Right. And tr

Andreas: passing style, but that's also very expensive, right?

Noel: Yeah. Yeah.

Andreas: so, yeah. Yeah.

Noel: And you probably get into all kinds of other problems too. The more kind of, you know, hacky like shim stuff you, you do there versus especially Yeah. Like languages that tend to use exceptions as control flow and all this, all this stuff

Andreas: Right. And the, the interesting thing is that the, the use of exceptions, although the mechanisms are all relatively similar across languages, the, the sort of culture of using them is quite different. So some really only use it for what they were originally meant for like. Exceptional situations. You like signal and error essentially, but others really got into the habit of using them as a control for feature.

Just like you can shortcut some loop or call chain, I don't know if [00:25:00] you found your result or wanna aboard or something

Noel: Right, right. Or try to do this thing. If you get an exception, then go do this thing instead, kind of stuff.

Andreas: Or something like that. Exactly.

Noel: Yeah, for sure. Okay, cool. Um, and let, I I, I do think, I do think the deterministic profile stuff is, is like academically very interesting. If nothing else can, can you determine or can you explain a little bit about, um, why like this kind of consistent execution is useful in certain contexts or why people are asking for this?

Andreas: So this is actually, uh, essential for some users of WebAssembly, which, and, and, but this is. So what is different here is, this is not something users want, but providers of a web assembly platform. And the obvious example is there are various, uh, blockchain systems now that run web assembly on the blockchain, right?

And blockchain means that you're relying on consensus for replicated [00:26:00] computation. Which means your computation must really be deterministic. Otherwise you won't reach consensus in any useful way. Right? So you really want reliable behavior to be the same everywhere and every time you execute it. So they absolutely need deterministic behavior and previously that kind of hacked around it themselves.

Um. For example, we time had a feature that allows you to normalize nans, right? So prior, prior to WEM three oh nan bit patterns was the only like piece of non-determinism web assembly. But uh, with relaxed sim we got more of that and kind of crossed certain red lines in a way, if you want. And so there was.

Uh, yeah, a pressure to kind of offset that by the ability, at least define what deterministic behavior would be. Right? So it's kind of like a subset, if you want, of the language in terms of behavior that is fully deterministic. It doesn't miss any feature, but it allows less. [00:27:00] Behaviors. Um, so it's well defined and if you build such a platform, you, you now have, uh, a spec to go to and, okay, this is exactly the behavior I I'll get, and maybe engines provide that for you and implement it, and everybody agrees on what it means.

That's really the old idea.

Noel: Yeah. What, what was, what you, you, you mentioned the, the relaxed MDE stuff. What, what, why, why did that kind of introduce some more non-determinism? Like what? Like what were the mechanisms in there that made this stuff not,

Andreas: Well, yeah, so it's basically, that was a very, uh, controversial feature in many ways. And because it, so the original philosophy of WebAssembly was like, we only put in stuff that is in the intersection of all major CPUs nowadays, right? But with sim you're getting closer to the cutting edge and people.

Like, especially in in machine learning, they really want to use the cutting [00:28:00] edge performance features. Uh, in sim unfortunately, the hardware vendors can, they can't get their shit together and agree on anything. So there are all like similar instruction sets. They all have, but they all disagree on edge cases and what happens

Noel: I see. Yeah. Mm-hmm.

Andreas: we wanted some way to under specify that essentially that all the behaviors are allowed and you don't have to normalize, which would basically ruin the whole point of using sym in the first place, right? If you have to normalize the result after the effect, um. And there are two ways you could do it, just one would be random, like non-determinism.

Like with Nance, you simply don't say what happened or. Like every time you execute something and it is in one of these undefined Edge case, you could get a different result. For some reason, that's not what they wanted. They also wanted some additional guarantee that when you ex execute certain instructions that they behave consistently with themselves.

At [00:29:00] least that made the story a whole bit more complicated. You now have a whole other dimension to worry about. It's not just non-determinism, it's actually implementation dependent behavior. When you look closer, and that is something I personally. Think is a mistake for something like WebAssembly that tries to be portable because it kind of blesses code that really tries to depend on that implementation.

Noel: right. It kind of leads, like leads to a false expectation 

Andreas: Yeah.

exactly. Um, but yeah, that's, that's where we are and that's how it got there. And so far, I think there, there was one company that who, who pushed a lot to get that in. Now it seems there aren't that many users at. Although it has been available for a couple of years already, so I don't know. Yeah, we'll see about that.

Noel: Yeah, that's a tricky one. Um, and I, I kind of, it kind of brings to, to, I think it's a good example of like, I'm sure a lot of this tension overall that you guys are kind of contending with it for so many [00:30:00] different. Like WebAssembly is such a, um, broad kind of, uh, you know, like noble goal that has like all these different use cases and all these different people want it for different reasons, and I'm sure that there is like a lot of tension between the different contenders here.

Andreas: Oh yeah, yeah.

Noel: yeah. How do you guys like balance that? Like what, how do those discussions go? What's the, like

Andreas: with heated discussions.

Noel: yeah, yeah, yeah,

Andreas: Um, yeah. I mean, sometimes the, the, the seniors among us, like who have been there from the beginning kind of point out that, oh yeah, but that was not the, the idea of web assembly when we started. And that is often an argument then. Okay. But. One, maybe one thing that is actually missing, and that is making some of these discussions difficult sometimes or people are surprised that we don't want to do something, um, is that we don't really have any like written down set of like, what is the philosophy of [00:31:00] like the rules of the philosophy of web or something like, you know, the zen of python or something

Noel: Right, right.

Andreas: like that.

Um, and. Maybe we should have that, but maybe also it might not be a good idea. Maybe we wanna stay flexible. I don't know. But usually, yeah, we, I mean we have the, the working group or community group meetings, and these are. Sometimes topics for heated discussion. And usually it then comes down to either we can find some compromise that we can converge on or the feature will not get in.

And there have been a couple of occasions where we rejected features because we didn't feel there are, um, in fit the spirit of WebAssembly. Like I can give one example that there was a proposal for. String built-ins, putting in strings as a primitive reference type. But that whole proposal was essentially driven by JavaScript [00:32:00] interoperability.

So the whole design was around, okay, make it cheap to pass strings back and forth from JavaScript. But that would also mean that you essentially standardized JavaScript strings, which are not particularly well designed thing, first of all. And also not necessarily what, what. The majority of languages needs.

So it would be a very JavaScript specific feature. And that's why some of us thought that now that let's not do that. Right. And that's why what we ended up with here in three O is instead these string built-ins, which are kind of more on the boundary there, not a primitive part of the core WebAssembly instruction set, but something that certain platforms, those that have JavaScript supply and you can import it as primitive.

So that is. Pushing it to the embedding then the core. Right. That makes more sense and that not everybody needs to support it.

Noel: Where are these, I guess, yeah, let's use this kind of, this, [00:33:00] the string reference as an example. I, I, this is kind of more just a, I'm personally curious, like where, where are these asks really coming from? Like who, who is the, who is the implementer? Who is the person that's like, this would help our use case a lot.

Like, or, you know, would, would give our end users eventually a better experience. Like what is the, where are most of these requests, kind of, of this nature? Like originating from.

Andreas: Um, I would say most of them prob, I mean, there are some things where we just, okay, let's fill. Some holes we left in the original design, like multiple memories was one of that. We already always anticipated that we will eventually fill this hole. Um, but originally we left it out for simplicity to get off the ground more quickly.

So that is something that comes from within the, yeah. CG or kind of then I guess the most common cases, language implementers. Right. Those who are close to the community group and they say, okay, I'm doing this. This kind [00:34:00] of thing here and, and it turns out that I would, could really make use of this feature.

Um, then there are, obviously, there are a bunch of things where you just know that this is a kind of general mechanism that many people need. Like GC is an example of that, right? It was always clear that we needed something like that. Cloths as well. There was wasn't any. Specific pressure there from already existing users because it's sort of a chicken and egg problem, they wouldn't even consider targeting web SEM without that feature, right?

So in some cases, the CG itself pushed forward some of these features to, um, solve this chicken and egg problem. Um. And, and then there are of course, but usually they, this is also driven by, by some users in the background who maybe want to use certain language, which doesn't currently compile to [00:35:00] web assembly, and this is what they need to make that happen.

Noel: Right.

Andreas: So GC was also in that kind of category? There was, uh, yeah, there was the desire for, for example, within Google to. To use WebAssembly for sheets and other of their applications, which are all run in Java. So they want to compile Java and as well co in to web assembly. So they needed some GC support and often that is sort of the, when there's like some big, big player there saying we want this, then that is what makes at least engine providers like Google.

Be willing to do the work for their customers, essentially, right? Because the whole process is anybody can propose something, right? That's not the problem. And you can push it through the process quite far without having to do a real implementation. But at some point our process requires, um, two, uh, [00:36:00] production engines to implement a feature.

Before it can be standardized and in practice that means two browser vendors. So usually that's now that, that, um, edge is no longer its own thing, and that's usually Chrome V eight. Um, and, and Firefox, they're usually, when they both agree, okay, we have enough interest in implementing this, then you can get a feature forward.

If they say, we don't care, then you have a problem.

Noel: Right, right, right, right. Yeah, I mean that, yeah, like as we said before, like we shouldn't only think about web, but there's probably, they are probably the two that most, where most of this code is running is probably those two. Um, yeah. Is there that kind of, that kind leads me to some, another interesting questions.

Now, now that 3.0 is out, um, like. Have you seen any kind of adoption, like making it through, into production, like workloads that have been, that you think are like having [00:37:00] high impact? Um, were there any like, uh, you know, cases that you could think just, you know, a standard, a standard user's like, oh, that's this, this tool you use all the time.

Now that we have 3.0 out is probably more efficient because now they're targeting web assembly for something like this, like, have you seen kind of tracked or seen any of those cases

roll all the way out to end users?

Andreas: Yeah, I mean, GC is already shipping everywhere and has been for a while. I mean, most of the features have actually been shipping for a while, so applications have already been using it for a

while. And GC like, yeah, when you, when you use Google Sheets or whatever, you, you run with 70 gc. Right.

Noel: it's a little bit, a little bit snappier now the memory.

Andreas: I, I dunno if that makes, I'm not a user myself of that. Um. Uh, but I don't know if I can pull out other examples out of my head right now,

Noel: It's a tough question.

Andreas: yeah. Um, but yeah, I mean, since most of these features were desired by certain parties, um, they probably [00:38:00] already used them, right?

Noel: Yeah, get picked up pretty quick. Do, do you expect that this kind of like adoption, um, across the browsers and engines is like, is pretty quick, like all, like people had a lot of these in place that for what they could already and, and stuff comes along quickly or are the, is that kind of a, a slow process?

Andreas: I think you can see all sorts of pace there. Um, there are early adopters. They're very slow adopters. I don't, I don't know if you can make like a general.

Noel: Statement. Yeah.

Andreas: Statement about it. Um, and usually it's sort of proportional to the proximity with a, with a working group.

Noel: Yeah.

Andreas: Like there are some people who really care a lot of it and want to push it forward rather faster than slower.

And they of course adapt it as as quick as they can. But then there are people who, for which it's really just a tool on the side and they don't care that much and don't stay up to date with what's happening necessarily. So.

Noel: Yeah. Which, yeah, I think like is is reasonable. You're gonna [00:39:00] have, you're gonna have all like, people that are like, have some specific use case, like, okay, our thing is done. Like, we don't really need that much new stuff anymore. Like, it's, it's probably fine. How about, um, I think this kind of leads leads my last set of questions here.

What is your, um, what do you think will define 4.0? Is there anything in particular that's kind of taking shape there that looks like it's the definitive thing people want or, you know, needs to get done next?

Andreas: so I, I, first of all, I'm not actually sure the next one will be 4.0, um, because we're now trying to kind of basically bump the minor version with every feature we merge and to sort of quicker release cycle. But that aside, I think the, the major two things that are still on our roadmap, or maybe three, well, two to three things.

Um, so one that has been in the making for ages as well is, is actual threading.

Noel: Hmm.

Andreas: Right. And that for various reasons has been delayed many times. Um, it's also has been shipping for I [00:40:00] don't know how many years in all the browsers, right? But. The first delay actually happened due to Specter. That was like right when it was supposed to ship.

Specter happened and everybody panicked and unshipped it. And,

Noel: Yeah,

Andreas: and since then, now it's mostly blocked on specification and memory model questions, which I hope we will get over, uh, next year. So, um, so that is a big one, I think, so that you can actually port p threads essentially to, to the web. For example, right?

Example. Um, and the other one that is, uh, filling another kind of gap for something that you can't currently compile well to WebAssembly is, uh, the stack switching feature.

Noel: Mm.

Andreas: So this is also something we have been

Noel: What? What is that?

Andreas: right? So like one thing that you can't compile easily right now is. Any sort of interesting control abstraction.

[00:41:00] So let's say, um, green threats, lightweight threats, um,

Noel: Hmm.

Andreas: uh, async a weight, sometimes generators, um, effect handlers, uh, coro routines, all these things. All they have in common is usually that you wanna suspend some computation and like hold it there and,

Noel: Do. Do

Andreas: resume another one. Right.

Noel: Yeah. Mm-hmm.

Andreas: For that under the bell, like of the implementation, what you usually do in native code is you have multiple stacks and switch between them, right?

So you can just suspend one stack and continue working on the other. But that is not something you can currently map to WebAssembly. Um, so that is a feature that enables you that to do that. Um, but. Um, keeping with the kind of safety model for web assembly where we don't actually expose stacks as, as the first class thing because that would be unsafe.

We have to make it a bit more high level, and the [00:42:00] way it's it's gonna be exposed is through, essentially we give you delimited continuations, if you know what that is. Um, so yeah, well you can think of it as core routines essentially, that you can pass values in and out of.

Noel: Yeah, the, the current, uh, ex like context, so there, are there any, are there any languages in particular where that won't work well for? This is like a very big question. I'm trying to, I'm trying to kind of like, you know, map, map these, you know, like a, a

Andreas: well, the, the question to ask is what, what are the languages that benefit from this, right? I mean, you can always not use the feature. That's 

Noel: That's true. Which, that's true. Yeah. Yeah, yeah. Mm-hmm.

Andreas: So, yeah, one, one example I mentioned was, um, green threats or virtual threats. So, for example, if you want to build a fully functional Java implementation right now, there are Java compilers, but they're single-threaded essentially, uh, [00:43:00] or use system threats, which especially on the web, are very heavyweight and not necessarily good.

Map for other things. Java 21 has this notion called virtual threats, which is essentially something similar, right? So if you wanted to be able to compile that to web with somebody, that's the kind of feature you need. Or if you want to be able to do Async eight, essentially, there are ways to do that without switching stacks, but they don't scale well.

That's what JavaScript engines do, for example. They do this kind of. Automaton transformation, which is really a form of, uh, continuation, passing star transformation, but that is costly and changes the a, BI and all that. Um, so with stack switching, in principle at least, that can be much more efficient. You could also compile generators with that.

Um, uh. Another more advanced feature, which some modern functional languages have is what's [00:44:00] called effect handlers. So there essentially a form of exception mechanism where you can resume, you can go back to the point that. That yielded the exception or raised the exception, and that is actually where the mechanism we're, we're implementing kind of took its inspiration from, from this sort of abstraction.

So you can go back there and then there are of course, like the more traditional continuation features, like if. Scheme or so, or this was something they have continue, uh, call cc or other forms of prompts and continuations. If you want to compile those again, you need this feature. Right? So basically every sort of control abstraction in modern languages, and most of them have many will, will be able to compile down to this kind of primitive in a way,

Noel: Yeah. Yeah. Kind, kind of, kind of mapped to it. Well, yeah, that's, yeah. I think you, you put it more succinctly than I could ask the question. Yeah. Um, yeah. Is there, is there, I guess, are there any, [00:45:00] any other features that you kinda wish you'd been able to get into, into three that are, you know, next, other, other than this stuff?

Or is this, are those kind of the, the front runners?

Andreas: Yeah, those are the front runners, definitely. So the, the big ones, um, and then there is smaller stuff, but none that is as. Interesting. I guess. I mean, there will always be smaller things we, we add on the side, like certain instructions, whatever. But in terms of big features that allow you to do things that you can't do right now, those I think are the two big ones.

Noel: Nice. Yeah. Cool. Cool. Um, nice again, we should, we should wrap here, but before we do, is there anywhere, anywhere, like if people are kind of interested in this stuff or they just wanna, they want to kind of see how either stuff's going on the implementation side or in the web assembly side itself. Like where would you recommend people kind of jump in to, to get involved

Andreas: It depends on how, how deeply you want to get involved,

Noel: want to go?

Andreas: So the, the Web Assembly [00:46:00] Community Group is completely open, right? So that is, um, basically all the proposal discussions and everything are, that all happens in the open on GitHub. So if you really want to know, you can just follow that, uh, the repository.

So that would be, uh. Well, there are several, but if, if you look at web assembly org, uh, then they will point you to that and you can also join the community group and participate in the actual meetings. So the main group has a biweekly online meeting, one hour on Tuesday, um, night or morning depending on where you are.

Um, and once a year roughly, we have a face-to-face meeting. Then like the next one will be in Munich, uh, in. This month, actually this month, in three weeks or something. 

Noel: nice, nice. Very cool.

Andreas: so yeah, in principle, anybody can show up there. All you need to do is for to register your email with the W three C, which has [00:47:00] our legal roof for doing this standardization.

And the only reason to do that is to get legal concerns out of the way that somebody might pull some patent card at some point.

Noel: Yeah. Yeah, yeah. Yeah.

Andreas: Um. So, yeah, if you really wanna know what's going on, then you can attend the meetings, or you can read the meeting notes, which will also be on the, on one of the reposts, uh, posted there afterwards. Um, but that might, might give you more than you ever wanted to know.

Noel: Yeah. Yeah. How about like, how about like, um, the, IM like the implementer side. Is there, is there an easy way to kind of find like, oh, whatever, I'm writing a specific language. Go find the, the people that are, are doing the, the compiler implementation step,

Andreas: You, you, you mean the compilers targeting web assembly or,

Noel: Yeah. Yeah, exactly. Exactly. The people writing

Andreas: we call the producers. 

Noel: the producers. yeah. Sorry, I forgive my

Andreas: Consumers and producers, consumers compile web assembly to native code, which are the [00:48:00] engines usually. Um, uh, yeah, so the producers, I don't know if there's, I wouldn't know that there's like a forum where they all. Meet, um, this is, I don't know, just many different groups working on some compiler. Right. I don't think there's any centralized thing other than the web assembly community group meetings themselves, where some of them at least regularly show up.

Noel: I am sure some good Googling or chat, uh, or L-L-M-L-L-M prompting could

Andreas: it's more like, okay, I'm interested in this particular compiler maybe so. Look for that and see if they have resources about it. Um, there isn't any central thing or

global 

Noel: Which is fair enough. I guess you prob like, it's probably kind of difficult with all the uh, as many moving pieces as there are all the time.

Andreas: Yeah.

Noel: and like different people targeting stuff. Um, yeah. But very cool. And I feel like, I feel like we covered covered a lot here, so thank you for letting me pick your brain a little bit under.

I I appreciate it. Um, and know you got got a lot going on. Your time's pretty [00:49:00] valuable right now, so I do appreciate it.

Andreas: Thanks for having me.

Noel: Of course, of course. It was great. It was great chatting.