mergeconflict389
===

[00:00:00] James: Well, welcome back everyone to Merge Conflict, your weekly developer podcast. Talk about all things in the world of technology. I am your host, James Montemagno and with me, my other co host, Mr. Frank Kruger. Welcome back, buddy. How's it going? 

[00:00:12] Frank: Hello, James. Thank you. It's been a long time. I had to take a little bit of a break from the show.

I hate to do it. It happens every year, every two years. I don't know. It happens from time to time. Thankfully, you found an amazing. Guest host to fill in and out, outdo me cause y'all talked about a topic. I wouldn't be very good at talking about. So, you know, Trixie, Trixie little game you, you played there, Mr.

Montemagno. 

[00:00:43] James: Can you believe that I got Heather on the pod? I mean, Heather had her own pod, but I actually got her to do a pod. We were, we were debating and she was dreading being, not necessarily being on the pod or having to talk to me for like an hour on the pod, but I think that. You know, as managers, we don't get to code as much as we'd like to, but, you know, you know, I don't know.

What did you think of the discussions that we had in general? 

[00:01:08] Frank: Oh, it was a fun discussion. Um, because I guess I still live in a world where Um, I've never really been a manager. I've been a tech lead. I've directed teams under me and, you know, but from a technical level, like assigning work and yelling at people when they didn't get the work done.

But I never had to, like, worry about people's careers. Or their emotional state, or really them as a human being. No, I'm just kidding. But, you know, I never really had to be a proper manager, as they say, a people manager. Um, so I actually, uh, I, I really tuned in to the discussion. I wanted to hear what managers had to say about managing.

And, um, Uh, I, I, I knew I was in for a good episode. I think Heather said like right in the beginning, she's like, all right, let's talk management. What do you got? 

[00:02:05] James: I was like, cool, ready. And she's ready. You're great. So I really appreciate Heather coming on. If you haven't listened to last week's episode, Heather, my partner, my wife.

Uh, joined us, uh, longtime C sharp NET developer. So she knows our audience very well, but then also like she became a manager right before me, uh, which was cool. Cause I'm learning a lot from her. We get to talk a lot about stuff and then kind of sharing a little bit about that was fun as well. So I'm glad that you enjoyed it.

And yes, welcome back and we're getting close to the end of the year, which is kind of crazy. Because we have this week and the next week's Christmas here. And then this January after that, so like boom, boom, boom. We're like holiday episodes. We're like dropping on Christmas, dropping on new years, like welcome.

Boom. So kind of wild. We'll be here with you the entire step. I hope everyone has some time off on it, but the world. Of development does not stop for holidays because Frank, I want to break down two and or possibly three or possibly five different, maybe 10 different pieces of technology, uh, that is exciting.

And I've had a lot of questions about, because I have been recently diving into the world of WebAssembly deeper and you've been there for a while, but Frank, there's new hotness. In the world of WebAssembly. So I want to break down today, a deeper dive on the video. I just put out on my YouTube about WASI, the WebAssembly system interface and how it relates to WebAssembly, obviously it's in the name, but then also what are the use cases, how is it different than containers and why people should care about this technology at all in general.

Right? So. Let's first break down WebAssembly. If there was a big, if I was editing this video on the YouTube later, they'd be like WebAssembly would be a cool graphic. So imagine that in your head, blah, blah, blah, blah, WebAssembly or Wasm as they call it, Frank, Wasm, Wasm, Web. Yeah. Why is it called WASM? It's like, 

[00:04:17] Frank: yeah, it's not a perfect acronym.

It's just, it's just 

[00:04:20] James: WebAssembly. Yeah. Just deal 

[00:04:22] Frank: with it, James. Yeah. 

[00:04:24] James: So do you want to break down what and how, and what WebAssembly is? And people may know of WebAssembly from the NET world, mostly because of Blazor, but it's not just a NET y thing. That's an open standard. And. NET and Blazor are just part of that journey, if you will.

[00:04:40] Frank: Also, you know, the little library called WE, I believe, was first to market as a public release that supported WebAssembly 

[00:04:48] James: very well. And WE. Yes, 

[00:04:50] Frank: anyway. Um, yeah, so WebAssembly, WebAssembly, uh, isn't it wonderful? It's a runtime. In the same way, NET is a runtime. It is a way to execute code within the browser.

That is, surprise, not JavaScript. Yay, everyone doesn't have to use JavaScript. And I say that, honestly, both sarcastically and not sarcastically. Because, uh, JavaScript is wonderful and everything. But, um Sometimes you want to use other languages and it's not the easiest thing to compile other languages into.

So we were given, the web gods gave us WebAssembly. And thank you, web gods. I don't, I think they're in Helsinki. I don't know where they are. Um, uh, It is a runtime, and it is also a programming language. It's an assembly language. You can 

[00:05:44] James: debate whether it's 

[00:05:45] Frank: a programming language or not. It's in the name.

Wasm. Um, it's really elegant, honestly. Um, they, they describe the virtual machine and the instructions. So assembly is usually an instruction, a source of data, and a destination for the data. Much like a function would take a parameter as its input, and output a result, or take an in out parameter, whatever.

Um, so they're like little functions, but they're baked in, so you can take a programming language like C, and compile C to WebAssembly, because it acts just like another machine. It's just another machine. Um, Just like a x86 machine, or an ARM machine, or a PIC micromachine, any of those kinds of machines.

And who doesn't love that? There's pros and cons to that approach, but the nice thing is compiler developers feel right at home, and you can get the most biggest Important compilers like GCC and I think eventually like, um, um, LLVM Clang and all those friends to output this as just another instruction set to those native languages.

And finally, here comes the NET C Sharp. And of course, we, we want in on that game. So of course, you can compile C Sharp all the way down to WebAssembly. The Mono people made it happen because They're like angels to the God of WebAssembly. I don't know, the analogy falls 

[00:07:18] James: apart. Yes. So problem before WebAssembly, there wasn't a way that you could just elegantly run your C sharp NET code in the browser directly, right?

If you think about ASP. NET Core, you have servers, you're clicking a button, you're going back and forth, have JavaScript. You don't want to write JavaScript. However, you do want to be able to interop with JavaScript. So the thing with WebAssembly is that you can run. The WebAssembly side by side JavaScript.

Like we do this literally all the time in Blazor. Right. That's literally how you can invoke into JavaScript. It's in the default templates. And like, I think you said is a good example is that you can think of them as like little WebAssembly modules that kind of like get loaded into the. The JavaScript app, like there's a WASM.

JS file. That's like doing stuff. Right. And the runtime is basically, uh, in this host of a browser. Right. So I think that's the thing to kind of remember here is like the browser is needed to implement web assembly support. Right? Just like today, if you wanted NET to run on iOS or Android or Windows or Mac or Linux, the NET runtime needs to run on those things.

So like somebody has to do work to make it run there. Well, the cool part about WebAssembly is that since it's a standard, A bunch of browsers, like browsers on my phone, WebKit, for example. Boom. It can, it can host it. Right. And Chrome can do it. Edge can do it. You know, any, any, anywhere. So now wherever you can, any supported browser can run WebAssembly, your C sharp NET decode can, can run there, which is like really elegant and really fantastical.

And if you want to write JavaScript too, you can, but you don't have to necessarily, but. You could. 

[00:08:59] Frank: Yeah. And it's really, um, it's a nice model because being a virtual machine, we all understand how to compile down to it and make our code run on it. The biggest downside is that it doesn't, it's, it's kind of an isolated virtual machine.

It does not have direct access to the DOM, so you can't just mess around with HTML and links and things like that. It has a very primitive memory model. You've got to write a tiny bit of JavaScript in order to provide it memory. Uh, there's another big limitation that I totally wanted to mention is completely slipping my mind now, but, um, well, I'll, I'll just say it's like, there's no operating system there, so there's no way that it's not like a Unix environment.

You can't just open a socket to connect to a website or something. Uh, the best you can do is bridge yourself up to kind of the JavaScript, or in our case, the Blazor C sharp world, and then let other browser features do all the heavy lifting of establishing sockets, what drawing to the screen, playing the normal multimedia things that you want to do in an app, touch events, you know, you, you gotta, you gotta write that bridging layer yourself, or use an awesome library like we are Blazor to 

[00:10:18] James: do all this.

NET MAUI. Yeah, and a lot of the, you know, Blazor libraries, right. That are out there. We'll do that bridging back and forth. And you're right about the DOM. That's where things can get scary. If you have stuff in JavaScript, that's modifying the DOM or wanting to modify the DOM versus like you're trying to modify the DOM, like who's controlling the DOM and the shatter DOM and all this other stuff.

So it gets a little bit tricky. And there are, so it's not perfect solution, but it does solve a use case and has been growing in popularity because like you said earlier. It's not just C sharp and NET. It's all sorts of different programming languages that are out there. You got the rest of the world.

You got the goes, you got the other things that are out there. There's all the programming languages want to be part of it. And to me, that's, that's pretty cool. Especially if you were in a. You know, big company, and you had a lot of different teams working on different things, using different programming languages, or collaborating with different people.

You could just jam some stuff together. Now you got a whole big world of WebAssembly goodness. Because it's, again, it's like you said, you're, you're compiling the thing into WebAssembly and executing it. 

[00:11:22] Frank: Yeah, yeah, and um, you can use web workers, so you can get real multi process stuff happening too. Uh, I like to try to run neural networks in the browser.

And we take full advantage of web workers and WebAssembly to accomplish that. The WebAssembly, because high performance numerical libraries tend to be written in C. So you have to compile them into a form that can run on the web. And then, uh, I believe it's still a single threaded model, but you know, WebAssembly is, it's a moving target.

It's, it's well implemented, well supported, but it's also growing. So, um, it's gaining features all the time. As far as I know, it's still a single threaded model. And so the. The trick for that is you spin up, you know, 10 or 20 web workers, each executing a web assembly. And all of a sudden you have a 20 process machine, concurrent machine, communicating through the DOM of all God awful things to use for that.

Um, and that's your synchronization mechanism. And surprisingly, you can build incredibly powerful things with that 

[00:12:32] James: setup. Yeah. And you can build entire. You know, web applications that run a hundred percent offline, no server in between. And that's what, you know, some folks need to use cases for. Now, Frank, the problem with this.

Is that you need a browser. What if you wanted to execute your web assembly outside the browser?

[00:13:00] Frank: No, don't, don't because it's too hard, James, as someone who has implemented several virtual machines and programming languages, it's too much, gosh, darn work. Don't do it. Um, I guess. You know, if someone actually asks me, okay, I wrote an app in this, but I want to turn it into like a native app or something, we give them the normal advice.

You write a native app, you put a web view in it, and you shove all your code into that web view, and bingo bango, there's your app. Um, which is a, honestly, a very valid way to write apps. Don't let my Tone of voice, lead you off. Go ahead and do it that way if that brings you happiness. Uh, but are you saying there is an alternative, perhaps, method?

[00:13:43] James: Yeah, I think of this away from the UI world. And I got a lot of questions of this on my video, which is like, well, yeah, what do you mean? Like, what, is there like some UI stack or blah, blah? I'm like, no, don't think of it like that. Think about of it as logic and functions and web work and, and, you know, not web workers, but workers and HTTP servers, things that don't require A UI necessarily.

Now they could, they could be invoking some things X, Y, Z in there, but imagine you want some workers that are interacting with something and you just want to execute these things or, or functions that happen now, you might say, well, okay, well, James, wouldn't I just write that in C sharp and NET and then I would just like run that where C sharp and NET run.

Sure, absolutely. Um, you could do that. In fact, you could also. You know, that into a container, right. If you want it to be modular, right. And then you say, okay, now I contain and I got a. Host OS. I got the runtime. I got the container. I got all this stuff inside of it. So you can do that, you know, so there's these different aspects that are in there.

But if you think about a WASM, you know, piece of code that you have, like a function or a HTTP server or a worker or something like that. If you think of that as a module, right? Like I want to take that module of code and I want to. Be able to execute it and run it anywhere, right? Now this might be places where, um, NET doesn't run today, right?

It might be some crazy embedded system. It might be some specific Linux distro. It might be, who knows what it might be, right? Or it might even be somewhere that NET is running, but you don't want Any bits of the NET runtime or any of the, you know, compilation there. You don't want to create a container.

Do you want the overhead of it? What if you just had the WASM code module, like executable basically, and you could run it. On a WASM runtime that basically ran everywhere. That means if you can compile your code, whether it's rust or go or C sharp or NET into WASM, then you don't need to worry about runtime to different containers and different images and different formats, as long as you have anything that can have a host for WASM or a WASM runner.

Then you could execute it. And that's one problem with, with it. Right. The other problem is basically having system access, right? Wasm today, WebAssembly doesn't have system access in a browser, right? So what if you want to access the file system across all these devices and all this, you know, the network and all these other things, you need some interface that could be implemented by the runner.

That could handle this stuff. And that is where WASI comes in. And it's the WebAssembly system interface that for all intents and purposes is a set of different system interfaces and APIs and methods that need to be adhered to, to have the system level accesses, um, for what WebAssembly code to execute.

So that means. If you have functions and methods and HTTP servers and all this stuff, you can compile it into a WebAssembly module and then execute it anywhere at all. Right. Any, anywhere in there. So it's kind of similar to like container D in a way, if you're comparing that to Docker and all this stuff, like it is kind of maybe like that.

That's maybe how I would put it there. Right. So what's really neat about that is that us as NET developers. We can kind of have this model and then compile the code and we can compile it in now many, many ways, right? We can just. Bundle the runtime into like something with a, you know, with a UI or whatever, or bundle, um, a full publish, right.

And, and get the NET runtime that we need. We could put it in a container and do blah, blah, blah, or we can pile it into WebAssembly and then run that in one of the runners. Which supports.net, for example, which should be, or, well, I guess any of them that, that's out there today, and there's a few of them.

Um, but one of them that was in Rich's blog and the one I demoed was a Wasm time, for example. It's lots of words you give me to it. Lots of things. So I 

[00:18:00] Frank: I I really wanna interrupt you so I could say Wasm time, 

[00:18:04] James: um, because I'll edit it. So imagine there's a world that did all this stuff. What could that be?

Frank James, 

[00:18:11] Frank: perhaps the best named console app I have ever heard of, wasm time. It's WASM time. 

[00:18:18] James: It's WASM time. You get it? It's time for WASM. It's WASM time. You 

[00:18:24] Frank: know, at first I was rolling my eyes a little. Um, the Let's start with the basics again. Uh, so I compiled some code into a WASM, a Blazor app, uh, a cool C ray tracer something into a WASM file.

Uh, now I can just run it at the command line because I'm a command line junkie. I like that. Yeah. Um, I don't have to bring up a browser. Remember the crazy JavaScript. Or anything to enter into it, it will just magically run because someone thought to use an interface file instead of . Um, whatever the browser thing.

This is super cool. I'm super excited for this. Um, I don't know if I personally am gonna have any direct needs for or anything, but I was like, I'm not sure I'm gonna use this until I found out the command line app is again named Wasm time and so for sure. I will, at least tonight, be compiling something so that I can run some WASM time.

Um, like you said, yeah, this is just the example runtime for running at the command line. You could embed this thing in a million different things in a million different ways. Uh, very cool. So really what I would say is, uh, WASM is growing up. It's, it's broken. It's, it's broken. But it's, it's left home. It's, it's left the browser and it's, it's just here in the world.

I guess I want to talk about all the stuff you'd said about containers, but mostly just one last time, I just want to say 

[00:19:56] James: Wasm time. Wasm time. Yeah. I think the other part too, is like, you know, Wasm time has like a security or Wasm has like a. Wasi, I should say WebAssembly system interface is as a security model around it as well.

So I think that is, is pretty unique. You know, I obviously, when my video showed just kind of running it locally, running it on Wasm time, whereas like I could give anyone in the world, or I could go into any Linux distro, I could just have Wasm time there. And then I could be executing that Wasm. module.

And that could be a WASM module that's in Rust or C or Python or Go or NET. And I could just run it, you know what I mean, without having to install any of the bits or other things or anything like that. And I also need to, I also don't need the NET runtime to be there to execute it because WASM time is handling, executing the WASM code, which is quite brilliant in many instances of it.

Uh, so. Again, as a NET, like iOS and Android developer, I'm like, you know, Oh, do I need to go like, what am I going to do with this? Well, it's not really maybe the use case for it, but I'm thinking like embedded systems. And I'm thinking maybe in the future of how I do want to execute code on the server, for example, put, put code on the server.

It might be a different way of, of, of, uh. of kind of bundling up my application, uh, as an option, you know. 

[00:21:23] Frank: Yeah. Um, it would honestly be kind of nice if Unix apps were shipped as little WASM files, because then you would have a little bit more control over the runtime environment that they're executing in, as it is, like a lot of Unix scripts are in, um, a scripting language.

But it's kind of nice that these are compiled down, um, Ah, I wonder if that for that reason it won't be taken off in the open source world where everyone does like all their, uh, not compiled things, you know, people aren't used to distributing O files or object files or A files. Usually just kind of ship around code.

Yeah. Anyway, um, super cool. I am curious, um, which parts of the operating system WASI, uh, covers. I've been trying to click through the documents. You might have seen my eyes bouncing around. Yeah. But it's a little hard to get through it, uh, seeing which API exactly they provide. But I do want to create, uh, actually mention a clarification on something I already said earlier.

I said I wasn't sure if Clang, um, LLVs c compiler was supported under m but the Wze, SDK Wze hyphen SDK on GitHub, uh, specifically uses clang as the compiler for the Wze SDK. And I just thought that was interesting because, um, I think it was GCC that had wasm support first. Um, again, if you're using T net, you don't have to worry about any of this.

It's built into NET, but I do have a lot of C code that I like to compile as WebAssembly. So that's why it just caught my attention. Oh, I can use Clang now. And it does support some Unix y features. I'm sure it just generates a whole bunch of code to talk to the WASI interface. But very cool to see this world really evolving.

[00:23:16] James: Yeah, it's neat. Yeah. Basically what they're doing and we'll put a link to Rich's blog post, but what they're doing is they have this NET WASM, which is for all intents and purposes. The NET Runtime in WebAssembly that's needed for the app. And then they can load your module and it can handle that. So that's going to enable you to execute your NET code side by side, like handle all this stuff for you.

So it's really, really neat. And he talks about a bunch of different scenarios and also the speed of them as well, which is pretty fast, you know, we're talking in some cases, if. You use WASM plus native AOT support, which is supported in this, which is crazy. I was about to ask you, I was 

[00:23:57] Frank: going to bring up that joke.

James, is native AOT supported? 

[00:24:01] James: It is funnily enough. It can be faster than the core CLR alone, which is kind of crazy. The native AOT is still like the fastest, which makes sense, right? There's still some layer there, but it's actually like. Pretty crazy fast, which is kind of bananas, you know, he talks through like, okay, like we could, you know, we could be doing, um, converting different, like markdown files into something else.

And like output outputting them to disk or whatever, we could create a little HTTP server that is like processing some stuff and just like running on some server or whatever, you know what I mean? Like small little things that are out there. So it is really, really new, but again, it is. You know, for all intents and purposes, kind of cool that there is actually WASI experimental support in NET 8.

So it's a NET 8 workload, and you say NET workload install WASI. experimental, and you get it if you just have NET 8 stable release there. So they shipped it as a experimental workload, which is cool. 

[00:24:59] Frank: Well, this is news to me. I think we should, uh, that's super cool. Uh, so there is a new workload named WASI.

Like hyphen experimental. Is that like part of the version number or is it just it's part of the name? 

[00:25:12] James: Wasi. Yeah. Dash. Yeah. Dash experimental. 

[00:25:16] Frank: Okay. Super cool. Um, I will definitely try that out because I don't know. I, I totally dig this for like console apps. And things like that. I don't know why. Yeah.

Same reason you like NET because it all bundles together. You can do the same thing. You can get NET to bundle into a EXE, you know, that contains everything that you could possibly want. Um, it's kind of fun to have like a whole different bundling technology available to us. 

[00:25:45] James: Yeah, well, and that's what I think is, is pretty neat about it is that you don't have to worry about where it's at or how it's running.

Just like, here's my files, just like execute that stuff again. It's like, you know, I think that, um, while today there's. You know, the SDK has some, you know, different support for like where it's going to run and all the other stuff it's going to give you, you know, more support for those other things like threading and all this other stuff and just different scenarios.

I think as a NET developer, I'm thinking, well, I might not need any of this, but I might, you know, someone else in my company might need it or someone else might need a use case, right? Like have NET part of that journey, I think. is really exciting to see, like kind of moving forward and, and, uh, and being part of this, this kind of next generation of early things, you know, it's like, I don't know, you know, crazy experimental new things on the internet, you know, just to kind of see NET part of that is pretty cutting edge, you know, when you think about it.

[00:26:52] Frank: Yeah, especially when you started bringing up the container speak, I was like, Oh, way to bring it like. Way to bring cutting edge to cutting edge, you know, we always have to mix our domains and everything. Um, again, I think it's just kind of the beauty of NET also that it, it is, um, it's, it's been a pretty fixed runtime for several years now, and that runtime's been able to be ported to other runtimes very easily.

So it's just kind of, it's nice that we're always able to take advantage of these new platforms and things like that. So, just another. A little shout out to NET for having a good design that's easy to port around when, when these kinds of new things pop out. I'm still waiting for my, um, NET native AOT GPU converter, you know, just tell, tell your friends that stuff, you know, that there are other forms out there.

WebGPU is out too. This isn't the only way to run native code on the web. So I want some NET love there, but yeah, absolutely. Um, it's always fun to see NET. Um, not just keeping up with the technologies, but in a way, like, it defined this technology of Okay, Java too. Hi, Java. Java and NET define this technology of, um, a tight little executable that can be run on any platform.

And the web has gone full circle from just being in the web browser and now onto machines. And it's nice to see that we're all just getting along and we're not drawing any like turf lines or anything crazy like 

[00:28:27] James: that. Yeah, I agree. And I think that there's a lot of additional new innovation that we'll see.

In fact, at Build this year, Mark Russinovich did this presentation. This is linked to in Rich's blog. It's very slightly mentioned, but basically there's this part of the presentation is called the Hyperlite. And Hyperlite is a new, um, hypervisor. It's lightweight and secure, and it's basically a WASM enabled cloud, if you will, of hypervisors being able to run WASM and doing this stuff.

So they demonstrate Blazor running in this new sort of lightweight hypervisor and spinning up. They're spinning up, like, I think he spins up thousands of, of these hyperlite hypervisors in milliseconds, basically creates them and starts them and runs them because they're so lightweight and doing this all in this sort of WASM enabled, you know, and they're all compartmentalized, right.

They're super secure little things, which is very fascinating, uh, in general. So yeah, to see that it's cool. 

[00:29:29] Frank: And, and that's the part I kind of jumped over because at first I said my eyes were rolling back when you said containers. I'm like, whatever, it's a, it's a compact, it's a packaged up little executable.

But I guess we call those containers now, which is super cool because, um, they are so lightweight that you can orchestrate them. You can kind of create more reliable systems. Um, it's kind of the Erlang lifestyle, lots of small processes communicating with each other. And. Maybe you do it through a HTTP server.

Maybe you'd use something fancier. But, um, as far as I can tell, like the WASI protocol just, uh, implements good old sockets, good old Unix sockets. And, uh, all the other protocols are built on top of those. So it's a pretty, uh, developer. Friendly world that we can live in there too, for doing our communications between little containers.

But it is fun to see the container world embracing web technology. There just aren't any borders anymore, James. We're all container app web developers now. I don't know what anything is 

[00:30:38] James: anymore. Exactly. It's a world I want to live in. Everything's everywhere all the time. Everything all at once everywhere.

Um, it's great. Cool. Anyways, that's mostly all I want to talk about. I want to, you know, I did a short little nine minute video, but that's all I have. What else do you have? 

[00:30:55] Frank: Well, I have the most fun little factoid also to, to just really heighten this discussion here. Uh, the, the dot WASM files, uh, those are binary files.

You can't like drag them into a text editor. They look like garbage. Don't do it. But did you know, there is of course a text version of WebAssembly files, because of course you can get an assembly dump from an assembly. Do you know what the file extension is for those files? No, it is a dot w a t what? 

[00:31:29] James: Ah, good old Watt files.

[00:31:30] Frank: Yeah. It's just a lovely file extension. And I insist that everyone distribute their WASM files as Watt files because it's way cuter than dot WASM. 

[00:31:41] James: Brings it back to my, I think, doom days, right? Everything was a Watt file, wasn't it? Uh, 

[00:31:45] Frank: those were WADs. You gotta place your tongue slightly differently in your mouth to say the difference with my lisp, but you can't tell.

[00:31:54] James: There you go. That's funny. Uh, it's cool. Yeah. I mean, there's a lot of stuff out there too. You know, I think it is evolving. Like they're, technically WASI is like a preview one. That's what this is on. Like, I think they're even saying for it on at nine, they'll just only be on preview two. Right. So it's evolving over time.

Yeah, but there are other things out there already, like there's WASI SQL, so you can kind of get like, uh, SQL support and things like that on it. There's all sorts of other stuff, like, that's inside of it, so kind of cool. 

[00:32:21] Frank: Yeah, as far as I could tell, it was just file system and socket, so communication and storage.

I did not see threading, so I'm curious, uh, if they will ever have a threading model, or if they're just going to embrace the multi process style of just spin up another process for every 

[00:32:38] James: WASM. Yeah. Oh, I'm interested to see how it, how it, how it evolves over time. But I wanted to give a little bit more detail.

I had a lot of questions about it. I'll link to it, all the things and stuff like that. But if you want to see it in action, check out my YouTube video. Only nine minutes. You can skip to the demo part. I have chapters on it. I'll just go there. So, uh, it's neat. The runtime, like the host OS and the runtime, like when you export those out, right?

The actual, like when you're, when you're CS proj, it's, it's actually like Wasm Wazzy or Wazzy Wasm basically. And it's like Wazzy is like the, the host OS and Wasm is like the, what is it? Let me look at it again. Um, yeah, the OS description is Wazzy. And then the OS architecture is Wasm basically. Yeah. So it's kind of cool.

[00:33:26] Frank: Well, thanks James for introducing me and I imagine others to a hot new technology. We all have hot new technologies. Hot 

[00:33:35] James: technology. Well, let us know what you think. You can run into the show, go to mergeconflict. fm or if you're on YouTube, which is youtube. com forward slash at mergeconflict. fm, uh, you can leave a comment on this video where Frank and I post videos and we do stuff.

So that's super cool. Um, but that's going to do it for this week. We'll see you all for the last. Episode Frank, which is episode three 90, which means just do lighting topics. That'd be easy peasy for the holidays. And then we're like 2024. So hope everyone has a great holiday. Um, if you like this podcast, you know, you can do stuff and that's it.

for this week. So until next time, I'm James Montemagno 

[00:34:13] Frank: and I'm Frank Krueger. Thanks for watching and listening. Peace.