WebAssembly is a portable binary-code format and a corresponding text format for executable programs to interface software for facilitating interactions between programs and their host environment.  Today on the show, WebAssembly expert Taylor Thomas shares his insights into WebAssembly and the endless possibilities for which it allows.

What's going on everybody? Welcome to another exciting adventure in the Adventure in DevOps podcast. And I kind of butchered that. So good thing I have some help in the studio today. I've got my co-host, Jonathan Hall.

 

Hey, I'm here for some adventurous adventuring of adventures of adventure.

 

Right?

 

Or whatever.

 

And I'm the, I guess I'm the host, although I'm butchering it completely. And then our guest today, Taylor Thomas.

 

Hi everyone, thanks for having me on. I work in the Department of Redundancy Department, just to help out

 

Hahaha

 

with the adventurers here.

 

This one's going to go well, I can already tell. Sweet. So Taylor, can you tell us a little bit about yourself and what you're into?

 

Yeah, I totally can do that. So like. Hi there, engineers. My name is Taylor Thomas. I'm currently an engineering director at a startup called Cosmonic. We work in the WebAssembly space and I'm sure we'll kind of cover some different questions about all that today. I have a big background in open source. I used to work at Microsoft with the Deus Labs team. I was one of the core maintainers of Helm for a very long time. Since

 

Oh

 

this

 

nice.

 

is a DevOps podcast, I'm pretty sure everyone here has at least heard of Helm, if not uses it daily. So you can curse at me later. I have all such the Kubernetes and container space before I was in WebAssembly. I've followed a lot of those tech trends through it. But yeah, just a big contributor to open source and then been involved in a lot of the newer WebAssembly projects as well. So this is a little bit about me.

 

Right on. So I've kind of tried to figure out WebAssembly for, I don't know, probably a couple of years now. So can you give us the high-level overview for someone who's not familiar with it? What's the deal with WebAssembly?

 

Yeah, so we have this joke kind of running joke among all of us doing this right now. It's neither web nor is it assembly, but

 

Yeah.

 

we call it WebAssembly. So the issue, the issue with that is that when it was created, it really took off for the web. And the what it is, a self-contained binary format that can be run on any operating system, which is obviously very important for the web, right? You like it'd be really lame if you got to a website and it's sorry, this doesn't work on Linux. The idea when it was created was just to say, okay, well, what if we took that, we're able to also bring all these other languages to the web? Because web applications, I mean, we all have a bajillion electron apps running on our computer. We're even probably what we're recording on right now is an electron app. And a lot of these things are done with something that's very compute intensive. And so what you want to do is something that was more efficient than, than say JavaScript and could be written in any language or a language that was meant to be used for this. And so that's where WebAssembly came in is that you could set, you could write it in multiple languages, compile it to a single target that runs anywhere. And then send that to the browser and then have it be executed in a completely sandboxed environment. And so that's, that's kind of where this started. And if you start to think about the many different things that are inside of the good for a browser, right? Like size, it's very small. The speed at which it runs, it runs at near native speeds. It has a sandboxed security model, what we call capability-based model, where you can choose exactly what it's allowed to do. And you also get the... the polyglot nature of it, that it can be written in any language. Those things are all really good for the browser. But if you stop and think about it for a second, those are also the things we desire on server side computing, right? We want completely sandboxed code. We want code that could be written in any language. We want code that runs really small and really fast. And so all those things that make it really good for the browser, make it really good for the cloud. And so when we talk about WebAssembly today, we're probably really mentioning in the cloud side, because that's where I'm currently. working with it. But it started in its popularity in the web and that's why it's got the name WebAssembly. It used to be called I think ASM.js or something like that. So beforehand, WebAssembly is neither web nor assembly but it's actually really good for both the web and the cloud.

 

So the fact that it's called WebAssembly, and it's neither web nor assembly, just means it's really in good company here on a show called DevOps, it's neither about dev or about ops.

 

Yeah.

 

Oh exactly. And we all have that debate, right? Like, well, it's not really dev, but we're not really ops either, so what do we do? I totally

 

Yeah

 

get that.

 

So I recently did a WebAssembly project actually, which I thought was kind of cool. In fact, I was at a Go meetup last night, which is neither about Go, actually it is about Go. So I was at a Go meetup last night and a guy who is working for the company that I did this job for, he kind of took my place when I left. He was commenting about how cool it was in this WebAssembly. So basically we had a little Go library and we wanted to be able to do a demo in the browser. So we just... compiled it to WebAssembly, added a little JavaScript wrap around it, and added some CSS, which I think the first version looked terrible because I don't know anything about CSS. But that's about the extent of my knowledge of WebAssembly. I've compiled a Go library into a WebAssembly library that is called by JavaScript. But I know that it does so, so much more than that. What are the actual, like, I mean, so I mean, I think... I think a lot of people who do WebAssembly, they think, oh yeah, we can compile whatever, Rust or C++ or whatever into the web now. But what else practical applications are people using WebAssembly for now? And what might we be looking for, say in five or 10 years?

 

Yeah, that's a great question. So the open source project that's behind Cosmonic that I've contributed to for a while is called WasmCloud. And WasmCloud's goal from the beginning was to be able to do something real with WebAssembly right now. So WebAssembly in the cloud, the big thing that kind of makes that possible to run on like server side WebAssembly things is called Waze. And that's a separate specification that's kind of under the umbrella of WebAssembly. And so the Waze spec has been maturing and improving over the past two to three years to be able to enable it. So there's gaps that we've had to fill. So it's not perfect yet. Pretty much every major language can compile to WebAssembly for the browser, but compiling to WebAssembly that works on the server. is a little bit more of an evolving thing right now. And so people can build a lot of real things with WebAssembly like right now for server-side computing. With WasmCloud and actually Cosmonec, so Cosmonec, our entire platform that is going to be basically hosted WasmCloud. things that are running for you, makes it really easy to run your code. You don't have to worry about the underlying infrastructure and stuff. It's actually 80 to, I'm sorry, not even 80. It's probably 90 to 95% built in WebAssembly. So we have built our entire platform on top of WebAssembly. And that's something we're gonna be releasing fairly soon here for people to actually play around with and look at. But when we do that, you'll be able to see like, it's a normal platform that you interact with like any other like PaaS type solution. And that's all running on WebAssembly. We've also seen examples from companies like Adobe and BMW and all these things where they're able to take things out and move them more to the edge. And so what you can start, near term is a lot of these things where the current solutions for running things. don't get you very far in terms of devices. So Kubernetes is the two billion pound elephant in the room with this. And having worked with Kubernetes extensively in the past, like I know what it can do and where it's kind of limits. And like there's been lots of efforts done. Like you have projects like K3S and all those different things that can allow you to run it on a Raspberry Pi. But once you get to a Raspberry Pi, even on there, you start to run to a limit. Docker and anything container related has a lot of overhead. You have to have the runtime for it. run it in constrained devices and it's not really set up to be something that runs all the way out to the edge. So and I'm using the term edge very loosely like many of the terms we use in this industry.

 

Yeah.

 

I'm not meaning just like IoT devices although that is included. It is also just things like think cell towers or or a lot of companies are starting to build up smaller, what they call edge data centers that are a lot closer to their customer, but they're not meant to run like all the huge, heavy workloads you normally run. And all of those things go all the way out to the edge. And it's really hard for Kubernetes to actually do that. A lot of the current paradigms make that very difficult. So short term, you're going to see a lot of these things that need to run across multiple devices. And we always like to joke around it. Although it is mostly true at this point, you can run WebAssembly stuff from a light bulb to a supercomputer and anything in between. And so you start to see where these advantages come along. And because it doesn't matter what the actual underlying operating system is, you start to get some really powerful ways of doing this. see that's a big trend in the industry is ARM-based processors. Everyone's building their own custom ARM-based processors. I mean, the most obvious one is the Macs M1s, all the Apple M1 chips and M2 chips, but you also have like Graviton, NAWS, and a couple of those different things. And all of those ARM processors are different targets than your normal like x86, x64. And as much as we liked to pretend that containers were cross-platform, They weren't, like they really aren't. They are still, like it is constrained to a Linux technology number one. Yes, there's Windows containers. I even met some of the people who worked on that when I worked at Microsoft, but they're an entirely separate thing. And you have to compile different images for every single target. In WebAssembly, you can even see this right now. A lot of the examples you see running from the different WebAssembly projects out there were compiled on some developer's machine, probably a Mac, maybe a Linux box, and it's running on a Windows machine, on an ARM processor, on this, on that, on the other thing, all with one thing. So you're gonna see a lot of that where you're trying to reach out to the edges, and I think that's the short term. And especially with things like with WasmCloud, we're aiming to have the idea of there's a flat networking line. So it doesn't matter even where you're running it. just run it. And so that kind of ability is very powerful for the short term. It kind of gives you a new way of running applications because instead of being able to have to like re-architect your application, so right now most time you build an application, right? You have this part, this part, this part, like you have the three different parts of your application. One might be like a database service, one might be like a user service, and there's all these different components in your system. And as that currently stands, you have to kind of architect how that's going to work beforehand. And with what we do in WasmCloud in particular, we allow you to stop thinking about that. We just say, write your code. And if you want to re-change how your app is architected, you can do that without any user changing pieces of code. So that's all near term. The longer term is where you start to see, well, what can we actually like replace and glue together? So imagine an application. I came up with this one when my team at DeusLabs, we called it chow time. It was just a fun example. Like pretend you have an app that gives you recommendations for places where to eat. So if you're running on your phone, maybe you don't want to use a lot of data, but like the application is still the same. So what if you could just swap out the component that does the processing for you behind it, the thing that actually says, okay, well, let me look at the database or whatever. And it uses a local database that's already downloaded on your phone. And then you could have a middleweight version. So let's say you are running like with a good wifi connection or whatever, you could have a middleweight version that goes and reaches out to like a big database of like pre-compiled results and things, and it knows how to recommend. Now let's say you're sitting on a big machine or you're willing to like spend the money to have like this piece of compute run on some sort of GPU enabled machine up in a cloud somewhere. Now what you're able to do is take that and say, now I'm gonna run that there instead. And so the application hasn't changed. And we're not talking just the UI, talking the actual business logic of the application hasn't changed. But the different parts of the application can. And so you could have something that's using machine learning, things that have come up and is recommending the most perfect restaurant for you, all the way down to, oh, I have this local database. And the person who wrote the application code doesn't have to care about what the backend thing is because that component can be swapped out willy-nilly and reassembled. And so you're able to assemble applications according to runtime characteristics without developers having to think about that beforehand. And also from the ops side, the operations people don't have to think about, like they can write the code that does the interfacing with whatever GPU thing. And the developer on the other side doesn't really have to worry about it to glue together those different parts of the application. So that was very long-winded, but there's a lot of cool possibilities here, and I kind of wanted to touch on some of the things that are short versus longer term that we see being exciting in the WebAssembly areas.

 

I don't want to sound too, what's the word? Um, I don't know. Sarcastic maybe pessimistic. I feel like I've heard a lot of your speech, about half of what you said. I feel like I was hearing back in 1996 about Java. What's

 

Yeah

 

the difference? You know,

 

You are not wrong.

 

you didn't, you didn't say the phrase right once run anywhere, but I heard you say that without saying that.

 

Hahahaha

 

said that phrase. I will fully own that. No, so that is totally a valid question. And we have that question quite a bit come up. It's started to come up less as we've answered it several different times. But really, we always think back to J2EEE, or J2EEE, however many E's it was, and all those different

 

I think it

 

things.

 

was 42 E's, wasn't it?

 

Yeah, like by the time like a tiny, yeah, it's I mean, it's Java. It's verbose, right? Like it's like enterprise

 

Yeah.

 

expansion extra. Eh,

 

There's a factory that makes those E's in there somewhere,

 

yeah,

 

so.

 

yeah, there's there's there's a J2EEE42 factory. And then anyway, so

 

Hahaha

 

we, um, the thing is, is we have to, we have to do, there's some things you can, you can pick apart with this, but really, I think the TLDR and then maybe one little extra detail there is that yes, we did say this once, but. I don't think the technologies were in the point when this makes it, when it, when it made it possible, you have an entire basically virtual machine you're running the JVM in the case of Java with web assembly, you're still running. You still have a runtime layer that's doing it, but it is much, it's much smaller and it is an actual polyglot thing rather than being Java or trying to compile to Java code. Um, Also, let's go back to the fact that it's the JVM. People have careers and good paying careers tuning the JVM. And so you don't have that with WebAssembly. WebAssembly is also really interesting in that it has the ability to choose, not only can you choose any language, but you can choose basically the compile characteristics at runtime. You can choose whether you're gonna JIT it,

 

Thanks

 

interpret

 

for watching!

 

it, AOT, any of those different things. So it, and look. Like any new technology, maybe it is going to devolve into some oozy mess in five years, who knows? Like we all know that that can fall apart. But when you look, there's very distinct differences as you see, we've also kind of... improved our technology. So if you look at the history of technology with how we run applications, we started off with basically like people running it on their PCs. But even if we skip past that, you have like the blades and you have like a server rack full of blades of things and the disks. I mean, I still remember, I still know the feeling of yanking out that disk drive and having to yank the arm out of your socket, like as you're pulling the drive out because it's spinning so fast. And... That's where we started. And so everything had its own like bare metal blade that you ran on. And I've worked at places even in the past 10 years where that was still what you did. And then we came along with like the VM era. We're like, oh, well, what if we could run multiple of these machines? And we came to VMs and you can now run three or four machines that were smaller and just constrained to what you need to do, but you still were installing whole operating systems. So then along came containers and we were like, hey, what if we just like made it even lighter? Like you can just use the same machine but now you have a virtual file

 

Thank you.

 

system. So everything's inside of a single unit of computing that you can move around. And we're like, oh yeah, that's a lot better. And that kind of gave birth to Kates and all the different like Kubernetes related projects. Let's run this distributed. And so. since the 90s when we had J2EE, I can't see, I'm never going to know how many E's it

 

Hahaha

 

is anymore. And so once we like, we moved past that, like that was back in the day when you had bare metal or VMs. And we moved on to containers and containers really were a... a force multiplying factor that comes into, I hate using business returns, but it really was because it enabled people to move their things to the Cloud. They got out of the business of running their own data centers. But you still had to worry, this is where I talked about earlier, that Docker really isn't cross-platform. There's still a bunch of dependencies in there. We move on to WebAssembly. WebAssembly, it's basically abstracting somewhat over a unit that can just run on a CPU. It doesn't matter what CPU, it just needs a CPU to run on. And that is a whole different paradigm of how you run an application than things were back in that Java era when people were like, right, let's run anywhere because we have the JVM. And so that's the kind of thing where I think we've seen that evolution. WasmCloud takes that even further because we say, hey, we don't care about your non-functional requirements. Like... Most developers don't. In fact, Java is the example to look here. When you had the log4j stuff that happened, now... I want to be very clear. I do not want to cast any blame on them because we've all written bugs like that. I have had many a bug that

 

Hear

 

I have

 

hear.

 

been like, ooh, that was bad. And so like, but the thing is, because of containers, everything was baked in. We've talked to tons of companies about this and people were upgrading thousands to even tens of thousands. They had to rebuild tens of thousands of Docker images to make sure that those dependencies weren't in there anymore and had the new version. of the dependency and then they had to redeploy that. And that is a massive amount of effort, even with CI, CD stuff in place. And what Wasm Cloud lets you do there is we've abstracted away those non-functional requirements that you then can connect into your business logic code. So your code is focused only on the business logic. And so now you have write once run anywhere, I'm going to say it, with the actual business logic. And that can literally run on any of these devices I'm talking about. And then it can be connected to a thing that provides it with its non-functional requirements. And so like, there's just kind of been an evolution of computing that has gone on over the past 10, 15 years of how we run things. And I think we're at a space where we've learned a lot from how containers works and all those things that make this very different than when we were approaching it from the Java side of things back in the late 90s, early 2000s.

 

So let me see if I can throw out an analogy and make sure I'm following this right. This sounds like, so in building applications, we went through this decoupling stage where you decoupled your database service or your billing service or in your email service from your main application. This sounds like decoupling, but at the binary level. Is that a fair statement?

 

Yeah, that is a fair statement. And I think that goes for just plain Wasm and also the stuff we do in Wasm Cloud. It's a decoupling of those requirements. And we can maybe touch on the component model a little bit later, because that's another like rabbit hole that will send people down at some point, I'm guessing. But it really is, it's detaching like, and saying, now these things are abstracted binary levels and you can re-glue them together as you see fit for your application needs.

 

Right on. When you build your WASM, do you have to target a specific CPU like you do, like you're building a Go binary, you target what the architecture is? Do you have the same case here?

 

No, it's actually your target is wasm32-wazee. It is a compiled target itself and that's what

 

Okay.

 

you build it to. And that goes for any language that has support for it. So go, I think you put like... Go OS none or go OS. I can't remember that. I have to go back and look, but there's like two, the, I think you said go arch to Wazi and then like go OS to whatever. And then Rust it's Wazim32

 

I'm sorry.

 

Wazi, Python, I think it's Wazim32 Wazi when you do like the, there's a couple of different things, but like, that's where we're talking about language support where the more language support that gets added, the more it just becomes part of your build tool chain, which is also what's really nice here because you're using your normal build tool chain that you've always used for whatever your favorite language is, to write your code and then you're just compiling it out to a WebAssembly target.

 

I think it's Go Arch is WASM and Go OS is JS, or maybe I have that backwards in Go. And the reason I know this is because I'm one of the maintainers of Go for JS. And we're trying to copy the, as much as possible, we're trying to follow the Go WASM standards so that libraries will work in both platforms.

 

Yeah, see, that's exactly those kind of things. And that's what people, all of us in the WebAssembly community are very happy for people like you who are trying to get these things working and going along. And yeah, with the Go stuff, mostly it's TinyGo right now. If you want to do a Wazitarget because of the things that have to be included. If you want to do web browser, that's the stuff that is mostly built in. And then there's other projects like Jonathan mentioned about making that a lot better for a lot of users.

 

So that brings up an interesting thing to talk about, and that is the output size. So you mentioned TinyGo, which does a really good job of creating very small compiled WASM from Go source, but it misses some of the key features of Go that maybe don't matter if you're targeting WASM, but some of them might matter to some people. Go for JS, transpiles Go to JavaScript. And then sometime after Go for JS was created, the creator added Wasm support to the official Go project. So now we can do a side-by-side comparison of JavaScript or of Go compiled to JavaScript or Go compiled to Wasm. And the Wasm is about 10 times bigger if you don't go with TinyGo. If you go with TinyGo, it's much, much smaller. It's like 100 times smaller. But if you go with the standard Go compiler, it's about 10 times bigger than the JavaScript equivalent. I don't know how this compares to other languages. If you're compiling Rust or C Sharp or something to WASM, I don't know what the output sizes are like. But I'm guessing that at least until we've spent a bit more time on this and we've optimized some of this stuff, we're going to have some large output files. What can you say about this? Maybe I'm completely guessing wrong. If there are large output sizes, why is that? And what can we hope for in the future?

 

So actually we've seen the opposite. We've seen that when you compare like two pieces of code that do similar logic to like the containerized version of it, even like a slim one, like built with Alpine and whatever, like a super small one, compared to what we have, it's about 10% of the size, the WebAssembly module is. And so that's what we've seen. Now there are

 

Nice.

 

some cases where it's different and this is where it depends on the language. So the reason why non-memory collected languages were like non garbage collected languages were the first ones is because you don't have that garbage collection thing that has to be brought in. And so Rust and C and C++ and those kinds of things,

 

Mm-hmm.

 

those all compile fairly small. And then you're also able to run it through some optimization passes that can make it even smaller. If you with certain types of WebAssembly stuff, like if you're using basically raw WebAssembly text files, they're called WAC files. those files are, when you compile them, are ridiculously small, like below a megabyte sometimes, depending

 

Mm-hmm.

 

on what your business logic is. But like, most of the time, we're seeing things between one to 15, but it depends on what you're bringing in. Like Rust is one of the bigger ones because you're bringing in a whole bunch of like language features. Like I'm using the term runtime very loosely here, but I'm to capsulate that like all the runtime features of the language are being pulled in and with it. The same thing happens when you compile something like Swift, which also compiles out to WebAssembly right now. that has fairly big binaries, but you're able to run it through optimization things that really start to shrink it down. Tiny Go is what we use for for Wazzy targets. So anything that's running on the server. And so those have also been small because it's Tiny Go number one and number two, it's WebAssembly. So in general, we have seen the things be much smaller than a comparable container. So you're

 

Mm-hmm.

 

saving a lot of space as well as execution necessities, because you're not spinning up a whole like container that is then running and taking up memory and in the process, you're just spinning up the very minimal amount of codes you need. So it has been the opposite for us, though as we see more of these garbage collected languages come in such as C sharp, which has basically.net supports coming in for this. Those things end up bigger because you're bringing in a garbage collector. So there's

 

Right.

 

only so small you can get because you have to have the garbage collection parts of it. I'm not sure if C sharp stuff is actually garbage collected yet or not WebAssembly, but there's the whole like, how do I bring my garbage collector in, is an open discussion and things that are getting solidified right now in the WebAssembly community.

 

Good, good point.

 

So it seems like if you're going to go down this path, that early on in the development process, you should probably rethink the architecture of your application in order to take advantage of this modularized approach. Do you have any resources on how to think about building applications or guides on building applications so that you can recompose them in this manner?

 

So it's actually more about understanding the how WebAssembly works and what the different things are. It's not as much. So I'm going to go ahead and show you a little bit of how WebAssembly works. So let's go ahead and get started. Well, let me put it this way. You can still architect your application the same way, whether that's in plain Wasm related projects or whether that's in something like Wasm cloud, you can still architect them the same way. Though you can get more benefits from maybe re-architecting them in different ways to be able to then scale them easier or spread them out easier. That is definitely possible. But a lot of it comes down to just making sure that you can, like a lot of times, once you can compile it into WebAssembly, to run it. And so the hard part right now is where those rough edges, because this is so new, meet that. Because there's sometimes when you're like, for the longest time, we didn't have the ability to do anything with sockets inside of raw WebAssembly stuff. We've coded around that with things in WasmCloud, but in raw Wazy stuff, you couldn't do it. We just got... We just got sock send, I'm pretty sure, in it right now. And so like, there's those kind of rough edges that happen, like things that just aren't supported in WebAssembly where you're going to have the most issues. It's not as much about re-architecting because a lot of us want to be able to play well with the current things. So for example, we created at Cosmotic, we created something called the Kubernetes Applier that just is, it's actually a WebAssembly module that's running and using our like non-functional requirement gluing, it's called capabilities, we see anytime we create something inside of like Wasm cloud, we then create a service inside of Kubernetes that allows people to connect back to it. And so most of the people doing things in this space are trying to make it so it's like, you're not like having to just go yeet the stuff out the window and start afresh. Like that's not the, that's not what we want people to do. We're trying to make it so that people can come in and say, okay, I just want to rewrite this one thing or I want to I think it would be a lot more beneficial and be a lot more lightweight. Like we've had plenty of people coming from like the Java space were like, Hey, I'm like spinning up like four containers with a full JVM that's running this thing. Can I please like run it smaller? And you're like, yeah, we can do that. You just have to rewrite it out of Java right now. But like you, you can pull that over and run those things. instead over in something like WasmCloud and still have it connect back. So we don't wanna just like have people throw it out.

 

Mm-hmm.

 

It's just more about finding the rough edges of WebAssembly sometimes when you're doing it, because you can't just take a lot of applications and just port them over wholesale if they're super complex. A lot of the stuff that's your classic, like what I call the crud apps, right? Like you're... Bread and butter of most business logic companies. Those are the things that can probably be easily moved over to WebAssembly because they're doing less of like something super advanced, you know, like calling some sort of GPU thing or like CUDA pipeline or whatever kind of crazy thing you're doing, they're not doing that. They're just doing basic, like, if this, then that, or calculate this value or fetch this data and do this thing to it kind of thing.

 

Gotcha.

 

So I'm going to ask some of my typical questions. I usually ask this whenever we're talking about a technology or a tool or something, just to kind of put it in perspective for other, for people listening who are deciding whether to use it. When should you absolutely not use WebAssembly? When is it a terrible fit for the job?

 

That is a good question. I'm glad that you asked those kind of things. So right now, as it stands, if you're running like... You shouldn't, we're not gonna see engine X running in WebAssembly, for example. Like that's a good, like anything that's like that, or like I mentioned before, like, oh, I'm running a big like CUDA pipeline to process this data across, but like not a good, don't even try like right now. Okay, sure, if you're adventurous, please try. We love those

 

If

 

things.

 

it,

 

But like,

 

yeah, this is for

 

if you're

 

fun,

 

like,

 

yeah.

 

I'm just gonna toy around with this, like no, that's not what you want to do. There's a lot of those things where you're like, where there's existing technologies that work. Like don't, I wouldn't try to like re-implement SQLite in Wasm yet. Like those are the kinds of things like stick away from those kind of like heavy applications that are already running really well in containers. But like I said before, the flip side is any of those like self-contained units of like business logic and stuff could go, are really good targets to try. So don't try any of the like. Any of the stuff that's using super advanced, like hooking into like lower level technologies, like a Postgres, like library or whatever, those things will probably lead to pain and suffering. So that I would avoid. I think in the future, those things could possibly be something that run in WebAssembly, but in the near term, no. Like just, like if you need a database or you need like... something like that, don't try to like rewrite it, don't try to do it, just use the existing technologies. Or if you're using like super optimized server libraries to like, if you're handling bajillions of requests per second and you already have something super optimized using whatever language is server library, like probably not the best idea to move that over right now because we don't have that level of like optimization and things figured out yet for similar server solutions inside of the web assembly space. Outside of that, I think you're okay to try out with many of these different applications. So hopefully that that answers the stay away from this, but you can do these things.

 

Yeah. Is there a reason to use WebAssembly for games? Whether in browser games or even Xbox games or anything like that?

 

Yes and yes. So people have

 

Okay.

 

done it for browser games already. I think there's a lot of different things. I mean, if you look at one of the ones I always point out, like Autodesk, if you're not familiar with Autodesk, they build 3D modeling software. You can have like full-on... modeling things that you're doing in the browser because of WebAssembly. And so if you can do that, you can do games. And I'm sure there are games that I don't know of. But using WebAssembly for games is actually we have a community member in the WasmCloud community who has written some basic game stuff in like WebAssembly running on WasmCloud. And so there are some interesting things here because, especially in WasmCloud's model, but I think you can also do this inside of WebAssembly with the component model being able to glue and choose things in place. to abstract out some of the processing parts of game design. So when you have to shoot something off and have it process a specific thing of data or to advance frames or timers that go along with it, you can do that as non-functional requirements that you write once and then everything can be reused by your individual pieces of the application. So I'm not saying someone should go write their AAA new game in WebAssembly yet, but we have had people trying this. they have enjoyed the experience of having it a little bit more portable than it was before. Like you're not tied to very specific architectures. And I have no idea if people like who are writing games for Xbox or PlayStation or anything are using WebAssembly because they could be, but we definitely see some possibilities there.

 

I have more questions, but Will, I'll give you a chance if you want to ask something.

 

No, go for

 

I don't

 

it.

 

want to dominate this conversation. How often do people write raw WebAssembly? Back when I did, like I did in university when I was writing assembly for an 8086. How often is it? I know it can be done, but how often does it actually happen and when would it make sense?

 

It's mostly for people hacking around and most of the stuff I've seen has been like, what? So like the web assembly text file, which is your equivalent of writing like assembly and then compiling it down to the actual like object files and things. So I don't see it super often. People who are doing some extreme hacking stuff where they need like very specific control over something have done it. Or if they're trying to write something that's super, super optimized, just like the same reasons you would see for writing something in assembly now.

 

Mm-hmm.

 

then they've done that. But most of the time I actually do not see that. I see people

 

Yeah.

 

using the languages with the best support for it, which are Rust and C and TinyGo and those kind of things.

 

So in that sense, calling it WebAssembly is kind of silly. I mean, aside from the fact that it's neither web nor assembly, just like

 

I'm sorry.

 

I don't talk about, I'm writing x86 with a bytecode. I mean, even though I am in the same way that I might be writing WebAssembly, right? You know, the compiler handles all that detail for me. I'm writing C or I'm writing Java, or maybe Java's not a good example because of the JVM. I'm writing Go or Rust or something. And yes, the output is some bytecode that can be executed by my CPU. But I don't talk about, I'm writing... whatever brand of CPU bytecode.

 

Yeah, no, there's none of that. And it's because it's a standard thing, right? It's the same, you're not writing it for, like you said, the specific CPU. You're not writing like, oh, this one has. forgive my lack of remembering all my assembly commands from college, but like, you know, like certain jump commands and certain types of register commands only exist in the x86 set and that like, there's none of that. You have the same set of things everywhere. In fact, even the memory that's exposed, it's just a linear memory thing that's exposed to a web assembly module that's running is the same. It's a standard thing. It looks the same on every single machine. How the machine puts it together is obviously machine dependent, but like the actual linear memory that's accessible for the code. is the exact same on every machine. So it isn't even the

 

Yeah.

 

same thing as assembly. Hence the

 

Yeah.

 

not it's not really assembly either but we called it WebAssembly so I guess that's what we're stuck with.

 

What kind of options do you have if you're doing something, maybe in the AI or ML space, maybe you wanna talk to a GPU, does WebAssembly give you that stuff, or will it in the future, or is that a silly question?

 

No, it's not a silly question. That's actually

 

Good.

 

one of the first things that people started talking about because of also the ability to like shift, once again, shifting these around and running them anywhere and then being able to like do specific. WebAssembly inference, sorry, machine learning inference stuff on it. And so there's a couple things. Built into the Wasi proposal itself is something called Wasi NN, that's Wasi Neural Networking. And that has support for, oh gosh, Tensor and something else. There's like two or three different things that are there. We've also had people, so we've had someone who worked at BMW who was working on some Wasm cloud stuff and they were doing some machine learning models and pipelines there. And so they use that with like, assembly things and I'm not even sure if they they needed like a specific capability but they they created that and made it so they could load like pre-built models to use for inference into the system and then run them. So we've had a lot of people actually look into it and I will fully admit, machine learning is a bit of a black box to me. Like I'm not like completely dumb about what it is, but like I don't know a lot of the details so I can't answer it in specific details, but I do know that there have been quite a few people who have been trying to do stuff with it and it's been a heavy area of interest since the beginning. So. I take that as a good sign that people are trying to do things with this and find a lot of value of doing this in WebAssembly as opposed to other existing options. They can see a future where this could be better for them.

 

What about quantum computing? Is there a quantum web assembly yet? Ha ha

 

Yeah

 

ha.

 

Yeah, yeah, we actually we build qubits in a in a web assembly now.

 

Awesome.

 

Just no, we don't. But I'm sure someone will come up with that.

 

I just did. Now you have to pay me for the trademark if you want to use that idea now.

 

Find your speed.

 

Yeah, exactly. All right, well, it's your turn.

 

Right on. So you talked about it being sandboxed. And so that's in the execution environment. So does it have its own protected memory space? And is that enforced by the runtime? Or by the, how has that played out on the host level?

 

Yeah, so there's two different parts of this. One is the actual sandbox capability model and one is the isolation. Like I mentioned before, each WebAssembly module has allocated a space of linear memory. That linear memory can grow, but like you, it only has access, I'm pretty sure it's the runtime that... that has access, that governs access to that. So when you try to do stuff, it's going to look for you. Now you can also pass it things, which is part of the capability model. You can pass a thing like an open file handle or an open like IO stream, and that's all it has access to. So when I say capability model, think like what happens on any cell phone nowadays. You open up an application, it says, this application would like to send you notifications. This application would like to access this, and you have to individually grant every single thing for it to be able to do it. So that's what WebAssembly works with. It works that way in the browser, too. It works that way here inside of the Wazii side of WebAssembly. You have to say, hey, I give you access to this file. You can access this file, or you can access this specific thing. Those are things that you are. you have to explicitly grant in. And then you're basically giving it like a file handle that it's then able to access and use the standard APIs for accessing a file that are built into the WSI standard. And so you have the memory enforcement that happens that I'm pretty sure at the runtime level, someone's probably gonna correct me on that and that's totally fine, but I do know that it is allocating a specific linear memory that is only accessible to that WebAssembly module. it's not accessible to other WebAssembly modules. You're not sharing that memory in that way. But then you also have the capability thing. So there's multiple layers of security there. And then we in WasmCloud add more security stuff on top of about signed things and invocations that go across the wire have to be allowed for it to be able to work. So like WebAssembly is a very good basis upon which to start building some interesting security options for making sure that code is well sandboxed and is not accessing. mentioned.

 

Gotcha.

 

I don't know

 

What

 

if there's

 

are the

 

a space.

 

requirements?

 

Oh, go ahead. You first.

 

What are the requirements on the host level to run Wasm applications?

 

It depends. So one of the other things that I really love, I mentioned that you can do different compilation styles, like you can do the AOT JIT, all those things, but like depending on your runtime characteristics, that comes into play as well with runtimes. So there is a plethora of WebAssembly runtimes because this is a... standard, it's actually really good. Like we aren't at like, there isn't going to be like a runtime to rule them all. It isn't going to be like Docker. I mean, I know there's other ones that run it, right? Like I'm not saying there aren't other OCI compatible things, but like Docker is kind of the way it runs. With,

 

Mm-hmm.

 

with, with Wasi stuff, you can actually have multiple runtimes. So Wasm time is the most common like. De facto implementation of the WASI standard you have WAMR which stands for WebAssembly Micro Runtime Which is basically WASMTIME Lite. You have WASM3 that runs it. So like there's a whole bunch of different WASM runtimes that are out there and they can all run the same built WebAssembly module, but they can run them with different constraints. So if you want to run on a super tiny IoT device, you could do an interpreted version of your WebAssembly module, not JIT, so that you're only basically reading in the instruction at a time and you could run it with something like Whammer or Wasm 3. So you could run this on a very, very constrained device because once again, I talked about the size. If you're... If you really, really optimize, you can get it down below a megabyte or just barely a megabyte or two megabytes, you're like not very big. So you're able to pull that down. interpret the different things in there instead, and then also be using that optimized micro runtime that makes it so you can run on those IoT devices. And so you can run it on big servers with the normal WASM time or whatever, but then on these smaller things, you can use these specialized runtimes for whatever use case you have. You could be running them on a big server, but have it optimized for something. I could see a future where... in like academic computing with supercomputer stuff, that you could have an optimized thing for supercomputers. That it's optimized to basically speed up how you're actually able to execute your code when you're in a supercomputer type environment. There's so many different things that could happen and that's a good thing. And so you're able to then choose what you need for the size and constraints of the device that you're going to run on.

 

Gotcha.

 

So, well, you actually asked my question.

 

Sorry.

 

But I, I, I, yeah, I know.

 

If you want to ask it again, we can have the editors just cut that part

 

Okay.

 

out.

 

I am actually interested in a follow-up though, and that is, so you talked about a megabyte or so. Is that the size of the executable or the WASM runtime, so to speak? Or both?

 

That's the size of the executable.

 

Okay.

 

The runtime is, oof, I need to... Let me see if I can look on my machine right now. Let me... Let's see the wasm time I have installed right now, which is a couple versions out of date is 13 megabytes

 

Okay.

 

It looks like and that's just the normal wasm time I the Like wasm clouds runtime is a little bit different because it's like a whole like host We were ready We're using a web assembly runtime and then we have our like application runtime built on top of it So it's a little bit heavier, but I know like in terms of memory usage that it's using it's like When nothing's running on it, it's like 80 megs of memory usage or like 90 maybe. And then, um, when we are doing a full like. I can run, we've tested this before, we've run tens of thousands of these web assembly modules, like replicas of them on my machine, and this is all running hot, not even running cold. And I can run like 10,000 of them before my machine starts to choke. But if we run just like a normal, you know, like, oh, I wanna run like five or six of these, and then like one of these providers, the thing that gives you your non-functional requirements, we're using like 110 megs of memory total. at idle. It spikes obviously when you have some more load, but you're not, we're not using a lot of memory and a lot of space here for most of these things.

 

So my question, my kind of ridiculous question was gonna be like, what old hardware could you run this on? Like if I wanted to run it on a 386 or a 286 or a Commodore 64, sounds like the Commodore 64 is out the door. Maybe a 286 or 386 might have the resources, assuming that the CPU has the capabilities we need, but.

 

I'm just gonna look for you because that's a great ridiculous question. How big the

 

Hahaha!

 

The

 

Thanks for hearing

 

The micro

 

me.

 

like yeah the WebAssembly micro went runtime Oh Gosh, how big is this one? It's like just the the core of it it is about 85 K for the interpreter and about 50K for AOT. So if you like took your, if you pre-processed your modules and did like an ahead of time compilation pass on them before you sent them to like a Commodore, you could probably actually execute it because it's only 50K to do an ahead of time one. And a very, and it says very low memory usage, but it doesn't give the numbers. So it is very small binary size to actually like run the thing. So I'm not sure if we could get all the way through running it on a Commodore or not, but we could try. I'm

 

Yeah,

 

sure somebody

 

maybe

 

will

 

a,

 

at some point.

 

yeah. If you have a Commodore and you're into doing this sort of stuff and you try it, we want to have you on the show, so shout out to all of our Commodore 64 hackers out there. I don't know why we're on this show, because it's not about DevOps, but I just want to talk to you, because it sounds really cool. Hahahaha.

 

Yeah.

 

And you're a brave soul if you're doing this. So

 

Yes.

 

yeah,

 

Yeah,

 

Yes.

 

for sure.

 

that's why anyone would wanna talk to you.

 

So from an operational perspective, you mentioned running multiple Wasm applications on a single instance. When you're looking at the running processes, do those show up as identical copies of the Wasm runtime, or do they show up as the name of the application that's being run? Does that make sense?

 

Yeah, it does. It just depends on how you're running it and where most of the time it's going to show up under like wasm time. A lot

 

Okay.

 

of people who are running this, including us, are actually embedding the runtime into the code that we run rather than like shelling out to a binary.

 

Okay.

 

So we're running it. And so when you see these processes running, it's still all within the same process of the. of the main parent. So you're gonna see it as like the WasmCloud host running, for example, then you'll just see how much memory the WasmCloud host is running, because it's not necessarily spinning out another process.

 

Gotcha.

 

But it's really interesting to actually see this because you get all the different parts of an application that are running and then you're able to glue them all together inside of WasmCloud and we're able to kind of give you a view of what's going on and how it's being used and whatnot.

 

Right on, yeah, I think that would be. really useful from my perspective just like when something spikes the memory or spikes a CPU you're like whoa wait what was that?

 

Another potentially ridiculous question was probably not as ridiculous as I think. Another big fad these days, and for good reason, is serverless. What does the intersection of WASM and serverless look like? If you want to run Lambda functions or your provider's equivalent.

 

Yeah, so I think it makes it a whole lot easier. Right now, every sort of like lambda or whatever is some super hyper optimized custom container that spins up and like everyone's talking about like how long it takes to start up and down. You don't have to worry, you're not downloading a container anymore. And so in the future, because like not every single language supports Waza yet, we're getting there. There's more and more languages that are happening every month of it. But like if we get, if we get something that they write in their own language into this, I should say, when we get to the future where we have this polyglot, everything would compile to Wazzy. And you have that. For any language, you can write in whatever language. And so it's easier both on the operator, the platform. They now don't have to write a very customized thing for Go and then for Rust and then for Java and then for this and then for that. And then for like, they don't have to write, there's a single thing that they can use. It takes a WebAssembly module that is smaller and easier for them to pull down. And there's caching that's already built into a lot of these web something things. So like if it's already there, you could just start it right back up and then run it and execute it a lot quicker because there is technically speaking a compile step, right? Like if you run it as a JIT, like you're compiling, you're doing the JIT compilation step, but like that's your only overhead and you can even like optimize that out of the way. So I see this as actually being one of the ways that people improve. this idea of serverless in the future, because instead of having to spin up all these things to run containers with, you just run it wherever you have some compute space and you run it real fast and real small. And so I think it is, like you said, I don't think it is a ridiculous question. I think it's a distinct strength of where WebAssembly could help in the near future.

 

Awesome. I think my last two questions, I could probably keep going for three weeks, but if somebody is interested in learning more, do you have resources, websites, books that you would recommend? And then the second, closely related question is, how do you get started if you want to start playing with this?

 

Yeah, so now's as good a time as any to jump in, really. There's some good things that kind of explain why we do WebAssembly. So one of the things that actually prompted this, how I think you guys found me in the first place, and then was a blog post that I co-wrote with our friends at Fermion, another WebAssembly startup, and Suborbital, which is also another WebAssembly startup, Connor Hicks and Matt Butcher. And hopefully we can link that. I don't know if you guys have show notes, but we can link that blog

 

Oh,

 

post

 

definitely.

 

in there

 

Yep.

 

Cause that one is a great one that just explains like, well, why, why are we having web assembly outside the browser? Why does it matter? Um, and kind of gives you the basic benefits. It should give you at least a baseline of like, is this worth me trying right now? And then after that, it's really just trying out a bunch of the different projects. So you can try out WasmCloud. We have a very welcoming Slack and community for people to jump in and get help with. You can try out all the different projects from Fermion. They have Spin that's quite popular that kind of helps people just get started real quick. And we have Suborbital has Atmo and Sat, which is their runtime for that.

 

Thanks

 

There's all these

 

for

 

different

 

watching!

 

projects you can try. But you can also just dive into Wasmtime itself. That's when it's a quick Google search. You just Google Wasmtime, and it'll pull up. And it shows you some basic examples of how to get started with it and then running a Web Assembly module. The reason I suggested our projects that I just was going through is because those allow you to build, even if it's a toy, something real. And that. then you can kind of play around with it and do like a comparison with what you currently do, with what you can do with WebAssembly. And all these communities are very welcoming. We're looking for people who are trying things out and are doing real things with them. And we're seeing some amazing stuff come out of it. Like we just have people just show up and be like, the guy who I mentioned who did the game, just one day showed up and said, hey, I wrote a game. And we're like, wait, what?

 

Yeah

 

And so like we love that stuff. And we just want people to get involved because the more people who get involved driving the momentum behind this. Like I said, the... The language gap is a great example here. We want to be able to support every language that's out there. And we get that by people who are fans of a certain language starting to use it and say, hey, I really just wanna be able to do this in language X. And that gets people paying attention and starting to use it. So those are some of the ways I always, and obviously I'm biased because I come from open source. So my default thing is just try to do some of the open source projects. There are some good books out there. I'm not, I'll be honest, I'm not a good textbook reader. I know a lot of you all out there I never read them. I just am not good

 

Hahaha!

 

at reading tech books, but History books I'll read all

 

I'll

 

day,

 

quit

 

but

 

writing

 

tech books

 

my book

 

no

 

now then.

 

So anyway, like that's just some options you have there that can get started. It is, there's a lot to kind of like get a grasp on like what's working. Like I've mentioned WebAssembly components, which like I said, is a whole nother rabbit hole that's really cool, but takes a little bit to kind of get a grasp on. You could also look at the talks from the last couple. So, I'm gonna go ahead and start with the talk. Cloud Native Wasm Days. It's one of the events that's co-located with KubeCon. And there's just been some really cool presentations there. People talking about how they're leveraging WebAssembly, what they're doing with it. And we're looking forward to one coming up here in October in Detroit. It's live streamed and it's in person. So if you're going there or going to attend virtually, you can attend that as well. And those things are going, I already have seen the schedule for it and it's gonna be really cool as we talk about these different things. And I think a lot of those will give you view of what's going on and allow you to select like where you're where you're interested in.

 

Awesome.

 

Right on. We will put a link down to what was the name of the conference coming up in Detroit?

 

Cloud Native Wasm Day.

 

Cloud Native Wadism Day, we'll put that in the show notes as well, because that sounds like it'll be cool. Sweet!

 

I think Jonathan said you had two more questions for me. So that was one of them. Was there another one or did I accidentally

 

I think

 

answer it by rambling?

 

I've marked out all the questions on my page. So I had a I guess I got to it somewhere. Or maybe

 

Hahaha.

 

that was the one Will asked. I don't know.

 

Hahaha.

 

Yeah, I did

 

Yeah.

 

steal the one

 

stealing

 

question,

 

my thunder.

 

so.

 

I don't know, anything else we should ask about or that our listeners should know about WebAssembly that we didn't think to talk about?

 

Well, I just, I think one thing that I would love to tell you, because this is a DevOps podcast, was talking a little bit about like what, what we're trying to do with Wasm Cloud and DevOps specifically. And this isn't like,

 

Mm-hmm.

 

this is the open source product. It isn't just Cosmonics. So I really am curious how people think and feel. And, and I like this idea of what we consider. with DevOps. So the thing with DevOps is we kind of had this, if you look at the history of DevOps, you had a thing where, you know, late 90s, early 2000s, back what we were talking about earlier, you had the, what I call the throw the trash over the wall version of this, right? Like you had your ops team and everyone would package up their application of trash and throw it over the wall and said, your turn. And so... the like that was that was what we used to have but then we came down to this kubernetes era and i feel like the pendulum swung way too far the other direction and i'm i'm hoping that a lot of people will uh relate to this in the devops community because i did like i do a lot of application development and like back into it now but i mean i helped build aks i built kubernetes i've done the devops thing and um All I remember with the problems of suffering and suffering I had there was that it swung back the other way and now everybody had to know ops and people were like, that's devops and it's like, wait, no. And that's why like people started calling themselves SREs because everyone who was a dev did it poorly. And as someone who does a lot of, I know I'm going to do certain things like from an op side poorly. And so what we've been trying to do, and I think what WebAssembly offers, and particularly Wasm Cloud itself, is it kind of brings that back to the middle, because it allows you to separate the concept of developers and operations, but not in the weird siloed way where someone throws the trash over the wall. Because one of the things that happens right now in Kubernetes that's a common thing is a developer says, okay, I wrote this application, I put it into a container, and the DevOps first responds with good reason because there's some security vulnerability or something, sorry, we don't support that base container. And then they come

 

Mm-hmm.

 

back. and they have to pick a different container, and then they come back and say, okay, well, we need access to this database. Can you please, well, sorry, we can't do that directly. You have to do it this way. And it just is this back and forth, and then you have to worry about constraining those resources and how they get, or they're spinning up like something that spins up a database, and you have to, so there's all this kind of nightmare behind it that makes it a pain in the butt for operators, people who are the SREs doing the job to actually do their job properly. And so what I'm hoping is that with WebAssembly and WasmCloud, like I said, we put that back in the middle because we've separated out these non-functional requirements. So now you can have an ops team that says, hey, we're providing your database access here. All you have to do is connect to these two inside of the WasmCloud system. But if we need to update something, we can update that non-functional requirement underneath you without you having to do a single thing in your code. So instead of like a log4j happens again, team having to go and say, well, let me go kick off all your pipelines and, hey, everybody, make sure to update this in your application or whatever. Or like, now you have this thing of where you say, hey, I'm just updating it for you. Like, I just hot swapped it. You didn't even know everything picked back up. And the people writing the code don't have to go ask the DevOps team for everything. They can just launch their code because the DevOps team can see exactly what's being connected, where, when, and how, and even restrict those if there's some sort of like high security requirements. We didn't really get to that. And I was thinking about that beforehand, about how that could be really valuable. And I'm curious what people think of it because I feel like that really enables both sides of the equation to do things well without doing the whole weird throwing the trash bag over the wall thing anymore. Where you still have to consider your DevOps team as a developer and as a DevOps SRE type person, you still have to consider what your developers needs are and you still have to work together, but you're not having this like, the developer manages all the operations now half the time them throwing stuff over the wall to you. So anyway, that was just something that we hadn't covered that I thought would be a really interesting thing. Maybe a little tidbit there to make people rage about or tell me good things about, I don't know which one, when they listen to this.

 

I think that's great. Although I do have a question related to that. I mean, in a sense, I think you solved part of the problem or that scenario solves part of the problem. But in a sense, don't you just move those dependencies into your compile time? I mean, if you're using log4j and you compile your Java application to WebAssembly, you probably still have log4j in your compiled output. So maybe it's easier for the developer to update build dependency. than a compile time of Pidacy versus a Docker image dependency. You see what I'm getting at? I mean,

 

Yeah.

 

you still have build dependencies, right, that might have security risks or something.

 

Actually, well, I'm going to say conditional no, because

 

Okay?

 

there's always build dependency stuff that could happen. Like there could be an underlying bug in the runtime, or there's all sorts of things like that. or like in the base communication libraries, but we actually inside of WasmCloud, we completely abstract those away. So logging is what's called a capability. You grant that it's a built-in one, but it's granted to the web assembly module to use, and then it just uses it. So the actual code that it's calling doesn't even exist in the built code that they're doing. Same thing, if they're talking to a database, instead of having to go update that database driver and get the specific database connections, they now they're just connected to a thing that provides the database connection. to them, provides basically the logic for calling the database. And so this happens inside of WasmCloud and then the component model, which is the whole idea of being able to glue together the different components can also do that. So instead of having logic that you... you build in entirely and it's compiled into the final static binary, you could have something that's saying, Hey, I'm calling something that's talking to a key value database. And you can take that component out and replace it with the other one. I mean, that's still a build time dependency in that case, but with Wasm time, you can actually literally hot swap those out. No things needed. Um,

 

Sounds like Pearl.

 

and so that's, yeah.

 

Ha ha ha 

Oh boy. Um, the memories, um, so.

 

We just lost all of our listeners. Everybody's like,

 

I'm

 

no!

 

sorry. I'm

 

not

 

sorry.

 

Pearl so yeah no but that's actually so wasm time for the most part you aren't coming so you aren't compiling in a log for 4j anymore, you're not compiling in a database driver. You're just doing your business logic only and then the logic you've connected in, your non-functional requirement logic is just connected in at runtime and is completely hot-swappable, as long as you are not doing a contract version upgrade. But otherwise, it's hot-swappable. So you can actually see that in one of the talks that I gave at one of those WASM days, actually that one is at KubeCon, where we do that live on stage of swapping out a dependency a bug to do it. So it does actually get rid of the build dependencies and makes it so that the operators can focus on, oh, hey, I found this bug in our logging thing, let me fix it. Or I found this bug in our SQL driver, let me fix it. That is a lot better because they have the flexibility to do that without interrupting their devs and not having to go bug their devs to go upgrade something for them.

 

So that means if I'm building a Go app, I'm not gonna use the standard Go logging library. I'm gonna plug into this capability, or I'm not gonna use the standard Go SQL driver. I'm gonna plug into this capability.

 

Yep,

 

Right?

 

that's correct.

 

Yeah. Cool. So yeah, so your conditional though, just to reiterate, a lot of these things can be taken care of if you use it correctly. Others, of course, not because there are build dependencies, but the overall surface area is drastically reduced by using WebAssembly.

 

Yeah, and it's compartmentalized, which is really, really nice, because now the logic for those requirements is completely separated, and so blast radius is contained to that if something goes wrong.

 

Super cool.

 

Right on.

 

I learned a lot today. Thank

 

Well, it

 

you.

 

sure was fun to talk about it. I love talking about this and it's, you both are great hosts, so it's been real fun talking about this and then making jokes about Pearl apparently, so.

 

Yeah. Any excuse to make fun of Pearl, right?

 

Yeah, that should just be a standard part of every episode.

 

Is there an Adventures in Pearl? I don't wanna piss those guys off. They might come over and start throwing

 

Yeah

 

tomatoes at us.

 

Cool, so should we move on to some picks?

 

We should.

 

All right, what have you got for us, Jonathan?

 

I'm not ready. I don't

 

Oh,

 

have any picks.

 

okay.

 

Come back to me. I had

 

I'll

 

something,

 

come back.

 

I just forgot what it was. So come back to me.

 

Taylor, you mentioned you had a TV series ready for us, right?

 

Yeah, I do. The new season of Star Trek Lower Decks has started up again. And I'm not a big fan of a lot of the new Star Trek, though I just started the Strange New Worlds, which has been good so far. But a lot of the new Trek has been kind of meh for me as someone who loves all the old Treks, like especially Deep Space Nine being my favorite. But Lower Decks is really good. It's one of those ones that is a good Star Trek thing while also making fun of itself really well. And so if you're a big Star Trek fan, they make a lot of funny callbacks and poking fun at things in the Star Trek universe while still telling like some really fun like Star Trek stories. So anyway, real good show, good laugh, fun humor. That's just something I've been watching recently and was super excited that it started back up again because the past two seasons have been real good.

 

All right on. That sounds cool.

 

I love

 

So I'm

 

it.

 

going

 

I

 

to.

 

haven't watched the second season yet. Sorry, I haven't watched the second season yet. I like the first one. So I'm looking forward to it. I feel like Lower Decks is kind of like... What was... What's the... Like the Orville, except in the Trek universe. Have you seen Orville?

 

Yeah,

 

Yeah.

 

the Orville and Galaxy Quest. They're like pastiches. They're

 

Yeah.

 

not parodies, they're pastiches.

 

Yeah, yeah. Go ahead, Will, sorry to interrupt you.

 

No worries, no worries. I'm definitely going to add that to the list, though, because it just sounds like something that would be right up my alley, especially with the humor mixed in. So my pick this week is the Thinker's Notebook, which is odd to pick a notebook, right, because they seem pretty straightforward. This one is actually pretty cool. It's really well-built. It's like substantial paper. But the thing I like most about it is I'm left-handed and no matter which page you're on, the notebook lays out flat. So you know whenever you do that like wrap your arm around 360 degrees so you can write, which if you're left-handed you know what that's all about. You can do that on this notebook regardless of which page you're on. So Thinker's notebook is my pick for the week.

 

Nice. I'm gonna pick a book.

 

on.

 

I first read Michael Pollan, I don't know, 10 years ago or something. He has a new book out called Your Mind on Plants. And it kind of follows on a recent book that he did, I think his second to last book, which was called How to Change Your Mind. But this book is basically a profile of three different molecules that are produced by plants that change the way we perceive the world. And I just finished the second section, which is all about caffeine and coffee and tea. But the other two sections are about basically peyote and poppies. So he's a good author. He does firsthand research on all of his topics, just

 

Hahaha

 

in case you're interested. But he does a really good job of covering things from all angles, not just the psychedelic angles, but the historical angles and the legal angles. And he's a very entertaining author. So I recommend the book, Your Mind on Plants. I'm listening to the audible version, which he reads himself. So if you like a book that's read by the own author, then this is a good one.

 

I wasn't sure where that was going to go. I was thinking, your mind on plants, co-author Snoop Dogg.

 

Ha ha ha 

 

But I do like the audio books that are read by the author. You seem to get like a whole new perspective, or maybe not perspective, but it feels so much more. personable, I think maybe is the

 

Yeah,

 

right word.

 

it's more, I don't know, like you feel like you get the complete experience the author intended.

 

Yeah, yeah, that's probably a better way of saying it.

 

Yeah. Cool.

 

Well, cool, I think we've got an episode here. Taylor, thank you so much for joining us. This has been a great chat, very informative.

 

Thanks for having me. It really has been fun to chat with you both.

 

Great, thanks.

 

Cool. Well, thanks everyone and we will see you all in the next episode.