WEBVTT 00:00.000 --> 00:15.120 Thanks for being here, my name is Dan Phillips, and I am going to talk to you today about a 00:15.120 --> 00:18.960 project of mine that I've been working on for a few years, and I've got to say I'm pretty 00:18.960 --> 00:24.240 excited to see this room so full at 9 a.m. the day after all the parties, that's pretty 00:24.240 --> 00:32.640 incredible. Yeah, so first thing, I'm going to start off just with a quick demo, just to kick 00:32.640 --> 00:40.240 things off, and then I'll move into the talk. So, people here, everyone here is used web 00:40.240 --> 00:47.440 assembly, yeah, for the most part, okay, good. How about Docker? Everyone used Docker? Yeah, of course, 00:47.760 --> 00:55.600 okay, good. Okay, so I have this project called Boxer, yeah. And there's Boxed CLI, I'm just going 00:55.600 --> 01:00.800 to kind of walk you through a quick example of what this can do, and you might see what it looks 01:00.800 --> 01:07.920 like, how familiar it is to you. Cool, so with Boxer, what you can do is you can take a Docker file, 01:08.880 --> 01:14.880 okay, a Docker file like this, this just runs a simple C program, that C program, 01:16.400 --> 01:23.600 is this one, perfect for a demo, prints a hundred lines, and it uses something from the standard 01:23.600 --> 01:31.600 library. This is very important. So, just to show you what this can do here, we'll do Box, 01:31.680 --> 01:44.800 build Docker file, do a Box LS, you'll notice that this is a little big for that file that 01:44.800 --> 01:48.880 I showed you, but we'll get into that in just a second. And then we'll do Box Run, 01:52.080 --> 02:00.320 and then here's the real kicker, what do Box Run, and the same exact thing runs here. 02:01.600 --> 02:07.360 Right? And how is that possible? That's possible because it's running the same thing in both environments. 02:07.360 --> 02:14.880 Right? The, what was just executed was a container definition, but all in web assembly. 02:15.280 --> 02:19.200 Right? So, I'm going to talk about this project, and I'm going to sort of talk about 02:19.200 --> 02:23.120 web assembly broadly. Actually, this room, I don't need a ton of explanation, but I'll kind of 02:23.120 --> 02:28.800 just go through it quickly. But quickly about me, my name's Dan Phillips, I work at a company called 02:28.800 --> 02:34.640 Lupole Labs. We do a lot of different things, some Wasm stuff, but also we do some interesting 02:34.640 --> 02:40.160 tech like live VM migration with no downtime, things like that. I work on this project called 02:40.160 --> 02:44.000 Architects Architect.run, should check it out. It's very cool, unrelated to the stock. 02:45.200 --> 02:50.720 On the internet, I mostly de-fil-a, de-a-nip-score-fil-a, on Twitter, X, whatever, and then 02:50.720 --> 02:57.440 LinkedIn, GitHub, and I also run the Wasm Chicago Research Group. It's a systems engineering group where 02:57.520 --> 03:01.600 we meet, read about things, and we have talks and stuff. So, if you're ever in Chicago, 03:01.600 --> 03:07.680 please let me know. So, what is web assembly? It's going to go through this quickly. 03:07.680 --> 03:13.120 Like I said, most of you in this room don't need this introduction, but just from the spec itself. 03:13.120 --> 03:17.760 Web assembly is a safe port of a low-level execution format, which is designed for efficient 03:17.760 --> 03:25.760 execution and compact representation. Safe sandboxed, it makes certain assumptions about security, 03:25.760 --> 03:31.360 and then no assumptions about leg, which is or host. Virtual CPU is the best way to think 03:31.360 --> 03:36.640 about it, right? Which can mean many things, but in this case, it just means a compilation target. 03:38.080 --> 03:45.360 It's a virtual ISA. It uses a bytecode binary format. It's an abstract stack machine. Yep, and 03:47.200 --> 03:51.360 what does that really mean? It's just another architecture. So, which is sort of the thrust of this 03:51.440 --> 03:56.960 talk. And because it's another architecture, we have to treat it like a compilation target, 03:56.960 --> 04:01.840 but there are some key differences, which is that it's virtualized. It needs a runtime, 04:01.840 --> 04:06.160 but that does not necessarily mean it needs to be interpreted. It means you can also do things 04:06.160 --> 04:16.160 like AOT and GIT and certain cases, and it's universal, right? So, most people outside of this room 04:16.160 --> 04:21.200 and other places, when they hear about wasm, they usually say, oh, no, no, I don't see 04:21.200 --> 04:26.880 very much front end stuff, right? And the interesting thing there is that, because it started off as 04:26.880 --> 04:32.960 a sandbox execution in a sandbox execution environment, and it makes no assumption about languages 04:32.960 --> 04:38.400 or host, it has things like extremely fast cold start times, and the nano to microseconds, 04:38.400 --> 04:44.720 which depends on the size. And it's a universal compilation target. There's really nothing in the 04:44.720 --> 04:50.640 spec about wasm being related to the web, or really being assembly, which is kind of a joke, 04:50.640 --> 04:58.560 in the wasm community. So, then sort of comes in server-side wasm. I like to think of this as 04:58.560 --> 05:04.160 cloud infrastructure's penicillin moment, where they saw these attributes of this technology, 05:04.960 --> 05:09.200 and they could squint and say, hmm, that's interesting, that could be used in many other places, 05:09.280 --> 05:16.800 right? Some people think of it like this, this sort of progression. We'll see if this is necessarily 05:16.800 --> 05:26.320 true, and this is so far been born out. It's smaller, safer, faster, and much more universal. 05:26.320 --> 05:33.200 Faster, having an asterisk, because many people say, well, it has a run time, so, therefore, 05:33.200 --> 05:37.840 must be slower than native, that may or may not be true in most cases, but when it comes to things 05:37.840 --> 05:46.800 like startup times, it can be much, much faster. I hate to use this quote again, but I feel like it's 05:46.800 --> 05:53.840 required. This is the founder of Docker talking about this about five years ago. This got a lot of 05:53.840 --> 06:01.120 VCs, but very excited back in 2019. And it's an interesting quote. He's sense sort of walked it back 06:01.120 --> 06:06.400 saying, he didn't mean that it would replace Docker. He just means that this was a technology that 06:06.960 --> 06:17.280 could have done many things back in the early days of LXC of containers. So, boxer, 06:20.320 --> 06:25.680 one of the most important things that I think is missing in the web of some of the community now 06:25.680 --> 06:33.680 is a developer experience that correctly abstracts away implementation details. I don't think 06:33.680 --> 06:39.280 that, and I think many people would agree, I don't think that we've quite found the right 06:39.280 --> 06:48.480 primitive for using WASM. So, this is a sort of, and when I say for using WASM, I mean as a general 06:48.480 --> 06:53.680 purpose compute target, right? There are many, many different ways that people are using it. 06:53.680 --> 06:58.000 At my company, we've built a thing called scale, scale that SH, which is a plug-in framework. 06:58.960 --> 07:05.680 Back here, we've got my friend Eduardo from Dyliv, and they have an awesome plug-in framework. Also, 07:06.560 --> 07:11.680 it's been really good in this sort of like polyglot plug-in space. But as far as general 07:11.680 --> 07:17.600 purpose compute, there's a, no reason that it can't be a general purpose compute target, 07:18.400 --> 07:25.680 much to many people's disagreements. And B, there's just not the correct tooling or abstractions yet. 07:25.680 --> 07:37.760 So, Boxer kind of takes a first look at this. So, Boxer takes your program. We start with a Docker 07:37.760 --> 07:45.040 definition, and then it builds a box. You can call it a WASM box, if you'd like. Very similar to what 07:45.040 --> 07:50.880 you can think about in a container is we have a base layer. We have a virtualized file system 07:50.880 --> 07:57.840 and system layer code. We have a compiled runtime. And then we have user source code. 07:59.120 --> 08:05.280 Most importantly, the only way that these different layers can talk to each other are through 08:05.280 --> 08:10.880 the process of imports and exports, which is fundamental to WASM modules and the separation of 08:10.880 --> 08:20.000 concerns. So, how does it do this? So, there's quite a bit at the lower level, but basically 08:20.880 --> 08:27.920 one thing that we think about with POSIX and with certain standards is interfaces. So, Boxer provides 08:27.920 --> 08:35.520 these interfaces, live-see-like, just call interfaces. And that creates the first layer. And that's 08:35.600 --> 08:40.720 sort of this from step here. You can do the same thing. So, once we have the virtualized 08:40.720 --> 08:48.160 file system set up, you can basically do exactly what you would do in a Docker container, where 08:48.160 --> 08:52.960 you bring in certain data, and it brings it into the guess. You can set the working directory, 08:52.960 --> 09:00.800 and you can set the command. So, the WASM BFS, this is sort of the bedrock of all of this, 09:00.800 --> 09:06.240 because for anyone who's done work with POSIX, you understand that everything is a file, 09:06.240 --> 09:10.000 even though everything is not quite a file. It's good to start away with a file system, so you 09:10.000 --> 09:15.120 can have things like file descriptors. So, the WASM BFS is sort of the bedrock of this. It's written 09:15.120 --> 09:23.680 in Rust. So, obviously, it's incredible. It implements all of the Cisco's that you would find 09:23.680 --> 09:32.640 in a POSIX file system, almost full POSIX semantics. Some key differences, though, 09:32.640 --> 09:37.040 is some things like syncing, flushing, locking that you would find in normal file systems are 09:37.040 --> 09:43.520 a little different, because of WASM's single-threaded nature by default, and a couple different 09:43.520 --> 09:52.320 architecture patterns. So, if you see here, you can see this project. You can see all of the 09:52.320 --> 10:05.760 standard exposed file system operations here. So, what that means is, if that's our base layer, 10:06.480 --> 10:12.160 we have a couple caveats. This whole project has just been me working on this by myself, right? 10:12.160 --> 10:22.160 So, I take that as you may. The POSIX surface area, we've reached about 70% and that means that we 10:22.160 --> 10:30.080 have implemented every single lib-c call that is promised to be in POSIX, every single interface 10:31.120 --> 10:38.720 at about 30% left. Networking. So, this is the interesting part. Networking, ENA Boxer, 10:38.720 --> 10:45.920 ENA Boxer, Boxer, it WASM Box. Does work, you can do networking through relays on the host, 10:45.920 --> 10:51.680 and in a distributed environment, you can do things like edge networking where you can specify 10:52.000 --> 10:57.520 where the networking relay will be sent through. So, how that works could be an entirely different 10:57.520 --> 11:00.400 talk. So, I'm not going to get into the details now, but if you want to talk about it, I would love to 11:00.400 --> 11:11.760 talk to you about it after. Okay, the lower layers. The way that this all works and the way that we 11:11.760 --> 11:20.000 can make this POSIX compatibility available is with a project called Markot. Markot kind of sets 11:20.000 --> 11:28.640 up the substrate of the system layers that will be used in AWASM Box. If anyone here has done any work 11:28.640 --> 11:35.120 with lib-cs, specifically muscle or g-lib-c, if you've ever looked at the internals, this will 11:35.120 --> 11:41.920 look relatively familiar to you, because this is a muscle-based lib-c, which also brings in 11:41.920 --> 11:48.720 g-lib-c functions that aren't in muscle, and it's kind of this Frankenstein of compatibility, 11:48.720 --> 11:54.960 but what this does is this sets up the system layers for every single WASM Box. So, each layer 11:54.960 --> 12:01.600 is virtualized where you have a file system networking, you have things like memory management, 12:01.600 --> 12:13.280 process management, signals, and that is all defined here. So, this is a list of every single 12:13.280 --> 12:20.560 function in POSIX, where it's implemented, and with notes about it. So, you can see that here, 12:20.560 --> 12:28.480 we have this C code, which is wrapping the WASM VFS code, which is in Rust. The introp is actually 12:28.480 --> 12:34.160 not as hard as you would think, but so this gives you file system compatibility, and then here 12:34.160 --> 12:41.120 we have self-contained functions, which are C standard functions, and then all the way down here 12:41.440 --> 12:48.800 is the remaining 30 percent of POSIX, which we are working on, which is things like process and 12:48.800 --> 12:56.560 thread management, signals, and this is where things get really creative in a web assembly environment, 12:56.560 --> 13:02.640 trying to make things like IPC work, like fork, like P threads, there's a lot that goes into that. 13:02.640 --> 13:11.200 Each of these themselves could be a separate talk, also, be careful, okay. And, yeah, you're okay, 13:13.200 --> 13:18.320 and so there's a lot here, but but basically know that there's about 30 percent remaining 13:18.320 --> 13:26.160 before you can run any unmodified UNIX POSIX-based piece of code as you would on a native platform 13:26.160 --> 13:38.960 in a WASM box. So, the big question is whether POSIX is the right way, so there are a lot of opinions 13:38.960 --> 13:48.560 about POSIX, there are a lot of opinions about system design, yeah, in the web assembly community, 13:48.560 --> 13:55.200 specifically there are some very heated discussions about this quite often, and it's anyone's 13:55.200 --> 14:03.760 guess. I'm not too dogmatic about it myself. I think that when it comes to ABIs, they get crystallized 14:03.760 --> 14:09.520 like they have in the Linux kernel over the last 30 years, and for better or worse, there are 14:09.520 --> 14:15.680 trillions of dollars worth of software that are running on POSIX, that people don't like to rewrite 14:15.680 --> 14:22.480 the lowest levels of their software, they like to run things on top of standards. So, yeah, whether 14:22.480 --> 14:26.960 or not it's right, could also be another discussion if you want to have a beer later and 14:26.960 --> 14:34.240 hash this out, I would love to do it with you. What POSIX defines though is, and I was just looking 14:34.240 --> 14:40.000 at the IEEE spec about the day, is it's just interfaces. This is a very key distinction. 14:41.120 --> 14:45.760 It's just interfaces. It defines behavior and interfaces. It does not say how you implement 14:45.760 --> 14:52.240 that behavior, which is a very important distinction when it comes to building something 14:52.240 --> 14:58.640 like a layer-based system for functionality, right? There's nothing in POSIX that necessarily 14:58.640 --> 15:03.440 says you need to use something like a monolithic kernel. There's nothing that says you can't use a 15:04.320 --> 15:10.960 microchernal or a unicarnal or no kernel at all, as long as the concepts are there and they can be 15:10.960 --> 15:16.720 executed. So, that's a very important sort of line that I've taken with this project, 15:17.040 --> 15:22.960 is that the interfaces will be fulfilled, but how they're fulfilled is quite different than 15:22.960 --> 15:31.360 in other places. And then what is a process, right? There's an interesting thing about the tyranny 15:31.360 --> 15:38.960 of the process in POSIX, just like the tyranny of file descriptors in POSIX. So, when you 15:38.960 --> 15:46.160 squint, for those of you who have done work with Wasm, a executing Wasm module kind of looks like a 15:46.160 --> 15:52.320 process, maybe. There was this idea early on in WebAssembly about nano processes and being able 15:52.320 --> 15:55.840 to communicate between them that's kind of evolved into this thing called the component model. 15:57.040 --> 16:05.200 But a Wasm module can communicate with other modules and externally by simple imports and 16:05.200 --> 16:11.440 exports. And the only thing that that module knows about is what is exported to it and what it also 16:11.440 --> 16:20.240 imports. This can set up a very different situation for things like IPC, communicating between 16:20.240 --> 16:27.360 processes, making new processes, forking, and things like that. And it also does stuff like 16:27.360 --> 16:33.040 remove massive amounts of overhead when it comes to communicating between different types of 16:33.040 --> 16:38.800 execution that are happening on the same system. So, there's also a lot there. Mark Haatt, 16:38.800 --> 16:44.800 this project handles the lower layers in Boxer. And that is, that could, this could be a 16:44.800 --> 16:48.160 whole other talk also. But I'm happy to get into it with you later. If you want to catch up. 16:52.640 --> 16:57.760 This is a picture that I had to actually be teammate for me. And it just kind of encapsulates the whole 16:57.760 --> 17:06.240 idea. So, just getting into some of the metrics. When we say that WebAssembly Boxes with the same code 17:06.240 --> 17:14.480 are smaller, safer, faster and more universal, there's a couple examples here. So, this is from 17:14.480 --> 17:20.160 a talk I gave earlier this year, the Python conference, the same code. And this is, this is 17:20.160 --> 17:27.040 excluding the container runtime. This is just the container images itself. And so, there's even 17:27.040 --> 17:33.120 more to this. Standard Python container, when the age of AI, this has become the defector 17:33.120 --> 17:39.360 language of the AI revolution somehow. And here we are. And so, Python images can be huge. 17:39.360 --> 17:44.000 They can take seconds, maybe 30 seconds, maybe 40 seconds to actually start depending on 17:44.000 --> 17:50.080 their dependencies. So, this is small one. And what's the security model? It's a container. 17:50.080 --> 17:54.480 If you know how containers are implemented, it does a lot to hide the rest of the system 17:54.560 --> 18:00.320 away. And it relies on having a kernel. It relies on having an operating system. It relies on 18:00.320 --> 18:05.920 having C groups. There's a ton of back and forth about how this is implemented. I gave a similar 18:05.920 --> 18:09.840 talk yesterday in the container room. And it's like, it's a completely different approach. But when 18:09.840 --> 18:13.440 you start to be architecture level and then build from there, the defaults are very different. 18:14.000 --> 18:21.920 So, the same code in a Wasm Box, six megabytes. If you pull out the source code and you snap 18:21.920 --> 18:29.040 shot the system code, about five megabytes and 500 kilobytes for the source code, same app, 18:29.040 --> 18:35.920 same exact app. Start of speed about 100 microseconds, depending on what's going on on the system. 18:37.200 --> 18:41.360 And this can be also shut down more with things like wiser, which do snap shoting, and then you 18:41.360 --> 18:48.400 can pre initialize memory in Wasm modules. And it's a completely different security paradigm. 18:52.320 --> 19:04.320 So, the future. In a perfect world, we have a paradigm shift to completely composable universal 19:04.320 --> 19:09.120 las and base operating system environments. That would be nice. It's probably not going to happen 19:09.120 --> 19:14.000 overnight, but there are a lot of things that we can do if we get the primitive right. There 19:14.000 --> 19:20.080 needs to be a way to deploy web assembly code without having to think about web assembly. That's 19:20.080 --> 19:26.160 my personal opinion, and I'm sticking to it. Just like when you use Docker, or containers, 19:26.160 --> 19:31.600 the vast majority of people who use Docker containers have no idea how secret works. Don't care, 19:31.600 --> 19:38.880 right? So, you also get, like I showed in the first demo, you actually get true isomorphism. 19:38.880 --> 19:46.320 Anyone who survived the Node.js hype of about 10 years ago remembers the sort of JavaScript I 19:46.320 --> 19:49.840 can write JavaScript here. I can write JavaScript there. I can write JavaScript everywhere. 19:50.720 --> 19:54.400 That turned out to not quite be true because the JavaScript is different in different environments. 19:54.400 --> 20:02.000 This is actually isomorphic. You compile it once, run anywhere. That sounds familiar, unfortunately. 20:04.800 --> 20:10.640 It turned into a, yeah, it turned into a compiled one to debug everywhere. 20:11.440 --> 20:17.440 Yeah, the difference here is that this is actually the same code, and it's actually in different 20:17.440 --> 20:23.920 environments, and it's not proprietary. It also doesn't bring a bunch of Java primitives into the run 20:23.920 --> 20:30.400 time. If you want to talk more about run times, talk to my friend Eduardo, he knows more than me. He's 20:30.400 --> 20:38.000 also a Java guy, so he can go back and forth with you on it. Yeah, so real isomorphism, very cool. 20:38.000 --> 20:43.920 But it's also isomorphism across even more environments. That same code that I ran earlier on my 20:43.920 --> 20:48.960 computer. I just showed you it ran in the browser. I could also take that same code and run it 20:48.960 --> 20:54.480 on an embedded device. I could run it on a microcontroller. I could run it across operating systems, 20:54.480 --> 21:00.560 across browsers. All of you likely have at least one wasm run time in your pocket, in your browser 21:00.560 --> 21:08.160 right now. It's on every major browser, all of the four ones, the four big ones, and that's 21:08.160 --> 21:15.840 really not going anywhere. There's this idea that true universality is more close at hand than 21:15.840 --> 21:21.920 it ever has been. Then capabilities based on micro services. I talked about imports and exports. 21:22.960 --> 21:28.080 If you've ever been to a container or Kubernetes conference, you'll see the vast array of the 21:28.080 --> 21:33.120 ecosystem that does things like identity, that does things like security, that does things like 21:33.120 --> 21:40.000 hardening the surface area for security boundaries on things that run containers, all of that. 21:40.000 --> 21:47.200 All of that could be disrupted or could not be needed if you simply had secure stacks running 21:47.200 --> 21:51.840 every single execution code and importing and exporting between those things in the same run time 21:51.840 --> 21:58.240 or across run times. Web Assembly gives you that out of the box, without having to do anything, 21:58.240 --> 22:02.240 because we started the architecture level and you have a secure execution stack for every 22:02.240 --> 22:08.880 single piece of code that you want to run. This is very similar to plan 9. If anyone's 22:08.880 --> 22:13.520 played with plan 9 or heard about this, the sort of dream that was almost realized, 22:14.400 --> 22:21.040 giving every single execution environment its own CPU. Well, if you kind of zoom out a little bit, 22:21.120 --> 22:32.720 that's exactly what Wasm does at a high level. Cool, thank you. 22:40.240 --> 22:46.160 Excellent question, not yet, but we will. And how will we do that? I don't know, maybe you can 22:46.160 --> 22:55.760 help me. Yeah, no, no, deal of is a tough one. Yeah, it's a tough one. So dynamic linking the 22:57.040 --> 23:04.560 rub here is that from a guest, so in Web Assembly, I went fast through this, but we have 23:04.560 --> 23:10.000 the concept of the host in the guest. From a single Wasm instance that is predefined, 23:10.000 --> 23:14.880 Wasm is needs to be confirmed that it's Wasm prior to running by the run time. 23:14.880 --> 23:22.240 So one of the things that is difficult now is spawning new processes from a process without 23:22.240 --> 23:27.280 communicating with the host. So we have to create these host functions, which can do things like 23:27.280 --> 23:33.120 mediate dynamic linking and loading, just like we do with forking and exacting. How that can work 23:33.840 --> 23:41.200 is challenging, but not impossible with things like snapshot and pre initializing. And you can do 23:41.200 --> 23:45.520 things like you can set up what's possible, so it'll probably start off by being like a very 23:45.520 --> 23:52.400 limited set of dynamic linking that you can do. Yeah, other questions. So it's not there yet, but 23:52.960 --> 24:07.200 if you sign up, I can show you. Yeah. Yeah. Yeah. Yeah. Yeah. And the master of the Wasm 24:07.360 --> 24:11.920 last month, before building is the point that we've talked about. Yes. 24:11.920 --> 24:16.800 The DCC, do you have a point like that? Yeah. So excellent question. 24:17.680 --> 24:23.040 The Mark Haunt Library actually wraps GCC or Clang depending on what you're on, and then it 24:23.040 --> 24:26.880 takes that and it converts it into Web Assembly for you, and you don't have to think about it. 24:26.880 --> 24:35.680 So when you do box build, you can, so both GCC, so Clang, LVM, you can compile C2 as 24:35.760 --> 24:39.360 pretty easily, but there are some exceptions. You can't compile it to like specific 24:39.360 --> 24:44.480 architectures like this, so basically we stub out all of the lib C files, and then you, 24:45.040 --> 24:51.120 it thinks that it's compiling to a native platform when it doesn't. Yeah. Yeah. Anybody else? Yeah. 24:51.600 --> 24:58.800 So I think you have some that you can build into what I'm trying to say about, so this is 24:58.800 --> 25:10.720 that you're multi-down nodes, the box itself is Wasm, right? Okay, but then the boxer will 25:10.720 --> 25:17.760 will bundle a runtime with it, depending on what architecture that you're on, right? So the box itself 25:17.840 --> 25:23.680 is portable. The runtime itself is not, right? So the idea there is you can take the same box 25:23.680 --> 25:28.480 and move it around run times, right? If you want to do things like networking, you'll need to 25:28.480 --> 25:33.280 bring in the specifics like you can plug in pieces to that runtime so that you can do things like 25:33.280 --> 25:38.720 networking, but you can do that by moving it across different environments easily if you have 25:38.720 --> 25:45.600 the runtime set up each one. Yeah, so a runtime is required everywhere. Yeah. Cool. Thanks, 25:45.600 --> 25:58.960 that. Oh, wait, one more. Yeah. Yeah. Oh, good question. No, the runtime's in the browser are 25:58.960 --> 26:06.560 pretty fast. There are some run times that are really fast on native and they're really small. 26:07.200 --> 26:12.800 It depends. There's slight differences between them, but there are some slowdowns depending on 26:12.800 --> 26:17.040 so each host is implemented in a specific language, right? And in the browser, you have to 26:17.040 --> 26:22.480 communicate with, well, I've assembly through JavaScript, right? There's some inherent 26:23.200 --> 26:30.400 unpredictable slowness there, right? With things like Wasm time or Wazeero in Go, it's a lot more 26:30.400 --> 26:36.160 predictable depending on what performance you want. The faster asterisk is because people always say 26:36.160 --> 26:40.960 it's virtualized how can it be faster? And I say, well, there's many things that are faster, 26:40.960 --> 26:45.920 like startup times or orders of magnitude's faster. And if you're doing stuff like this where you 26:45.920 --> 26:51.920 are virtualizing the interfaces for what are usually ciscalls, there is effectively no overhead 26:51.920 --> 26:56.080 in terms of context switching like you would get with kernel, right? And so if you have something 26:56.080 --> 27:02.080 with high like IOPS, then you multiply that a billion that is, you know, that is much, much faster 27:02.080 --> 27:08.960 in terms of certain things. So it's a, it's an asterisk for that reason. Yeah. If you want to 27:08.960 --> 27:12.720 talk more about it though, we can chat. All right, I should let my friend get up here. 27:12.720 --> 27:17.760 So, time's up. Okay, yeah, thank you.