Pass to remove some "like"s.

058-wasm.txt

@@ -26,7 +26,7 @@ C: That's right. The Spritely Institute, of course, I am CTO, has announced that
 
 M: Yeah, and it's got an awesome name. It's called Guile Hoot.
 
-C: Yeah, that's the internal name for the project in a certain sense. So actually, it has this cute pixel art owl. We were debating, we were like, "It needs a cool name and a cool little mascot just for ourselves." And I just happened to have this pixel art owl I drew recently. And everybody's like, "Oh, this is pretty good" because we were talking about maybe a bird would be nice. And so, Guile Hoot became the name. Now if everything goes well, in the long-run, it is very possible that there will be no 'Guile Hoot' in that everything might get merged up stream to Guile proper. And so this might just be a temporary project name. We don't know. Could be that some pieces stick around as their own independent thing. But yes, very exciting that WebAssembly, we're getting to work with it more day to day. And this project is being funded by the MetaMask folks who, you know, very passionate about Spritely and want to make it happen and want to be able to see our stuff in the browser also. But, you know, if you've been following us for a while, you might know that I am personally excited about WebAssembly. I think it's a pretty interesting project. And we'll get to why as the episode goes on.
+C: Yeah, that's the internal name for the project in a certain sense. So actually, it has this cute pixel art owl. We were debating, we were like, "It needs a cool name and a cool little mascot just for ourselves." And I just happened to have this pixel art owl I drew recently. And everybody's like, "Oh, this is pretty good" because we were talking about maybe a bird would be nice. And so, Guile Hoot became the name. Now if everything goes well, in the long-run, it is very possible that there will be no 'Guile Hoot' in that everything might get merged up stream to Guile proper. And so this might just be a temporary project name. We don't know. Could be that some pieces stick around as their own independent thing. But yes, very exciting that WebAssembly, we're getting to work with it more day to day. And this project is being funded by the MetaMask folks who are very passionate about Spritely and want to make it happen and want to be able to see our stuff in the browser also. But, if you've been following us for a while, you might know that I am personally excited about WebAssembly. I think it's a pretty interesting project. And we'll get to why as the episode goes on.
 
 M: Yeah, to start off with, just a reminder, this episode is about WebAssembly in general, not specifically about the Spritely project.
 
@@ -38,19 +38,19 @@ C: WebAssembly, it's an abstract-- what's called a virtual machine. You might be
 
 M: Yeah. And this is built on Lisp, right?
 
-C: Sort of. So, the textual syntax looks a lot like Lisp. And if you program in it, it feels a little bit like kind of a combination of Lisp and Forth and assembly all together. So you can program in it by hand in this Lisp-y syntax, and it compiles down to a binary syntax, but it's basically a stack machine with a lot of very serious discipline, which means that you are pushing values onto the stack and then running operations that eat those values and then put other things on it. It's kind of like a stack of cards that it keeps like kind of putting things on and then like eating the cards off of the stack and it kind of grows and goes up and down.
+C: Sort of. So, the textual syntax looks a lot like Lisp. And if you program in it, it feels a little bit like a combination of Lisp and Forth and assembly all together. So you can program in it by hand in this Lisp-y syntax, and it compiles down to a binary syntax, but it's basically a stack machine with a lot of very serious discipline, which means that you are pushing values onto the stack and then running operations that eat those values and then put other things on it. It's kind of like a stack of cards that it keeps putting things on and then eating the cards off of the stack and it grows and goes up and down.
 
-M: And this makes it so that basically you can get like all of the languages in the browser, right?
+M: And this makes it so that basically you can get all of the languages in the browser, right?
 
-C: Yes, that is the reason that the name 'Web' is in WebAssembly. It's not necessarily something (as we will talk about later) that is only restricted to the web. But the exciting thing is that the browser has been the domain of kind of being this universal deployment target for these things that everybody can run and use. And therefore people are like, well, you have to write JavaScript because JavaScript is the language of the web. One of the things that's kind of compelling about WebAssembly is that that's not the case in that WebAssembly opens up the possibility of every language being a first-class citizen on the web.
+C: Yes, that is the reason that the name 'Web' is in WebAssembly. It's not necessarily something (as we will talk about later) that is only restricted to the web. But the exciting thing is that the browser has been the domain of kind of being this universal deployment target for these things that everybody can run and use. And therefore people are like, "well, you have to write JavaScript because JavaScript is the language of the Web". One of the things that's kind of compelling about WebAssembly is that that's not the case in that WebAssembly opens up the possibility of every language being a first-class citizen on the web.
 
 M: Yeah. And it's also a general deployment target, right?
 
-C: That's right. There's a project called WASI, which is a WebAssembly interface system. It's interesting because it's kind of capabilities oriented, and it's also kind of POSIX-y. So like POSIX is like the kind of standard for Unix stuff. It's basically like, okay, you have this virtual machine. You can do all sorts of operations on it, but how do you simulate all the things that you might want to do in a program, reading and writing from files and getting input from the keyboard and all sorts of things like that. And so WASI is built for that purpose. And it also so provides some capability protection architecture in the design. So yeah, there's been a lot of excitement about WebAssembly also being just this general purpose target that you can compile to. And then you can, you know, run these programs anywhere, basically.
+C: That's right. There's a project called WASI, which is a WebAssembly interface system. It's interesting because it's kind of capabilities oriented, and it's also kind of POSIX-y. So POSIX is the kind of standard for Unix stuff. It's basically like, you have this virtual machine. You can do all sorts of operations on it, but how do you simulate all the things that you might want to do in a program, reading and writing from files and getting input from the keyboard and all sorts of things like that. And so WASI is built for that purpose. And it also so provides some capability protection architecture in the design. So yeah, there's been a lot of excitement about WebAssembly also being just this general purpose target that you can compile to. And then you can run these programs anywhere, basically.
 
 M: Yeah. And a few years ago, you and a friend started a kind of small group called "It WASM Me", right?
 
-C: Yeah. So Tristan, a friend of the show, has appeared on it before. And we ran this little user group. We called "It WASM Me". We both wanted to understand WebAssembly. So we were hand-writing WebAssembly in its WAT syntax, the WebAssembly text syntax, which is again very lispy. And we were just writing very tiny programs just so that we would understand it. You know, when we ended it, we were working on implementing Conway's Game of Life in handwritten WebAssembly. What I wish that had existed at the time, but didn't-- There's a project that exists now called WASM-4. And it's basically like a tiny fantasy console. So you know, we gave a whole episode about the tinyNES, right? And that's a real video game console that existed that people could play games on. And fantasy consoles are basically this idea of like this imaginary, imagine if you made this old retro computer. And so there WASM-4 is like this extremely restricted fantasy console. And so if we had done it today, I would have said, we would try to have written our programs to write out to WASM-4. But when we were doing it, we were just manually hooking in the interfaces we needed to the browser so that we could like, print things out and also write to a canvas and stuff like that.
+C: Yeah. So Tristan, a friend of the show, has appeared on it before. And we ran this little user group. We called "It WASM Me". We both wanted to understand WebAssembly. So we were hand-writing WebAssembly in its WAT syntax, the WebAssembly text syntax, which is again very lispy. And we were just writing very tiny programs just so that we would understand it. You know, when we ended it, we were working on implementing Conway's Game of Life in handwritten WebAssembly. What I wish that had existed at the time, but didn't-- There's a project that exists now called WASM-4. And it's basically a tiny fantasy console. So we gave a whole episode about the tinyNES, right? And that's a real video game console that existed that people could play games on. And fantasy consoles are basically this idea of this imaginary, imagine if you made this old retro computer. And so there WASM-4 is this extremely restricted fantasy console. And so if we had done it today, I would have said, we would try to have written our programs to write out to WASM-4. But when we were doing it, we were just manually hooking in the interfaces we needed to the browser so that we could print things out and also write to a canvas and stuff like that.
 
 M: Yeah. Every time we've brought "It WASM Me" up in public, people have asked if this was a user group that they could join. Is this something that you would be interested in expanding or making more public?
 
@@ -62,7 +62,7 @@ C: But yes, when every time we've mentioned it, various people have gotten excit
 
 M: Yeah. Let's talk about the extensions to WASM.
 
-C: Yeah. So I mentioned that it's a stack machine, and it's very minimalist. Like the base, core, what's called the MVP, the minimum viable product version of WebAssembly is very basic in some ways. And you can do nearly anything, but it's so minimalist that it's usually-- like the main thing is that very few people end up handwriting WebAssembly programs, the way that Tristan and I did. Most people are using something like Emscripten, which compiles C programs to WebAssembly, or they use something like C or C++ or they use something like Rust to compile things. So they're going to be using a language that's not one of these low level languages. They would probably compile the whole interpreter or whatever for that language and then run the program, but that's very expensive. So part of what we're doing at the Spritely Institute is we're trying to advance the usage of these proposals in terms of WebAssembly being a first class language platform. So for example, if you're writing these low level programs, then you're probably doing manual memory management or just using the stack. But if you're using a dynamic language, you might be using something like a garbage collector, right? JavaScript, Scheme, other languages like that, have a garbage collector-- Python. The problem is, the garbage collector goes and removes things that aren't needed anymore, goes and picks up the garbage, right? But if you are running this on top of something like, you're running it with the browser and with the host JavaScript, how do you end up, saying, okay, JavaScript doesn't need this anymore and your program doesn't need this anymore. You kind of have to kind of synchronize those things. And so the garbage collection proposal allows you to use the host garbage collector, and you don't have to port over a garbage collector. And there are all sorts of other extensions that are kind of in-progress, like multiple-value return and the delimited continuations proposal and other things like that. We're not going to go into those in this episode, but let's just say that there are some interesting extensions that are being worked on to WebAssembly. And I think part of the value of Spritely pushing forward the Guile WASM stuff is hopefully we will help push forward and advance the ones that are really necessary to get a lot of different kinds of these dynamic languages to be first class citizens in the browser.
+C: Yeah. So I mentioned that it's a stack machine, and it's very minimalist. The base, core, what's called the MVP--the minimum viable product--version of WebAssembly is very basic in some ways. And you can do nearly anything, but it's so minimalist that it's usually-- the main thing is that very few people end up handwriting WebAssembly programs, the way that Tristan and I did. Most people are using something like Emscripten, which compiles C programs to WebAssembly, or they use something like C or C++ or they use something like Rust to compile things. So they're going to be using a language that's not one of these low level languages. They would probably compile the whole interpreter or whatever for that language and then run the program, but that's very expensive. So part of what we're doing at the Spritely Institute is we're trying to advance the usage of these proposals in terms of WebAssembly being a first class language platform. So for example, if you're writing these low level programs, then you're probably doing manual memory management or just using the stack. But if you're using a dynamic language, you might be using something like a garbage collector, right? JavaScript, Scheme, other languages like that, have a garbage collector-- Python. The problem is, the garbage collector goes and removes things that aren't needed anymore, goes and picks up the garbage, right? But if you are running this on top of something, you're running it with the browser and with the host JavaScript, how do you end up saying, JavaScript doesn't need this anymore and your program doesn't need this anymore. You kind of have to synchronize those things. And so the garbage collection proposal allows you to use the host garbage collector, and you don't have to port over a garbage collector. And there are all sorts of other extensions that are kind of in-progress, like multiple-value return and the delimited continuations proposal and other things like that. We're not going to go into those in this episode, but let's just say that there are some interesting extensions that are being worked on to WebAssembly. And I think part of the value of Spritely pushing forward the Guile WASM stuff is hopefully we will help push forward and advance the ones that are really necessary to get a lot of different kinds of these dynamic languages to be first class citizens in the browser.
 
 M: Yeah. So that is what WASM is and how it can be extended. But why should we care?
 
@@ -74,11 +74,11 @@ C: Well, I was showing it off at the Hack & Craft. Yeah, WebAssembly.sh, it's an
 
 M: Yeah, your interest in WebAssembly started with some encounters at T-PAC several years ago, right?
 
-C: Yeah, so T-PAC is W3C's--the World Wide Web Consortium's--big annual conference for standardization stuff. And a few years ago, I had the good fortune to attend live, and I had some extra time and I could go to basically anything I wanted. And I'm like, "well, I'm really interested in finding out what this WebAssembly stuff is and like, are they actually doing things legitimately? Like, is this something that we should follow with earnestness?" And so I went into this room and kind of watched them talking about things, and I was just really floored by the quality of people that they had brought into the room, the quality of the conversations they were having. And we've had Mark Miller on the show, Mark Miller was part of those conversations and Mark and I spent a bunch of time talking about how the GC proposal would work afterwards. And I was also surprised to find out that--if you listen to this show, you know, we talk about capability security and why it's important a lot--That capability security was being very seriously considered for WebAssembly. I was like, wow, this is like, this could really bring these ideas like quite broadly to the rest of the world. And there were two very memorable things that happened at that event, as in terms of just kind of funny side stories. So one of the things was that there was this one person who I was sitting next to, and they were like, "oh, yeah, I'm just working on this little toy project". They're like, "it's a Scheme that compiles to WebAssembly". Now, of course, that's funny because Spritely Institute is now doing a scheme that compiles to WebAssembly. And they're like, "and then, I'm going to make it so that it can compile itself. And I've just been fooling around with it during the middle of the meeting". And I was really excited to talk with them. And I'm like, "well, I actually think that the kind of Lisp-y syntax is one of the things that got me most excited". And they said, "you know, we didn't initially start out with Lisp-y syntaxes in terms of what we were planning on using. We were saying, 'well, we can't agree on a syntax right now. And we'll just use this Lisp syntax for the moment until we come up with something better'. And then I guess like what always happens with Lisp is we ended up coming to like it."
+C: Yeah, so T-PAC is W3C's--the World Wide Web Consortium's--big annual conference for standardization stuff. And a few years ago, I had the good fortune to attend live, and I had some extra time and I could go to basically anything I wanted. And I'm like, "well, I'm really interested in finding out what this WebAssembly stuff is, and are they actually doing things legitimately? Like, is this something that we should follow with earnestness?" And so I went into this room and kind of watched them talking about things, and I was just really floored by the quality of people that they had brought into the room, the quality of the conversations they were having. And we've had Mark Miller on the show, Mark Miller was part of those conversations and Mark and I spent a bunch of time talking about how the GC proposal would work afterwards. And I was also surprised to find out that--if you listen to this show, you know we talk about capability security and why it's important a lot--That capability security was being very seriously considered for WebAssembly. I was like, wow, this could really bring these ideas quite broadly to the rest of the world. And there were two very memorable things that happened at that event, as in terms of just kind of funny side stories. So one of the things was that there was this one person who I was sitting next to, and they were like, "Oh, yeah, I'm just working on this little toy project". They're like, "it's a Scheme that compiles to WebAssembly". Now, of course, that's funny because Spritely Institute is now doing a scheme that compiles to WebAssembly. And they're like, "And then, I'm going to make it so that it can compile itself. And I've just been fooling around with it during the middle of the meeting". And I was really excited to talk with them. And I'm like, "Well, I actually think that the kind of Lisp-y syntax is one of the things that got me most excited". And they said, "you know, we didn't initially start out with Lisp-y syntaxes in terms of what we were planning on using. We were saying, 'well, we can't agree on a syntax right now. And we'll just use this Lisp syntax for the moment until we come up with something better'. And then I guess like what always happens with Lisp is we ended up coming to like it."
 
 M: "We'll use Lisp until we find something better."
 
-C: And then they don't. Nothing better emerges. So there's that. And then the other thing that happened was I was just overhearing these people talking, and they're like, "well, the amazing thing about WebAssembly is the way that it ended up coming from ASM.js". So there was a few years ago, there was a person named Kripkin who Mozilla had hired. He was working on a project that I was really excited about, which was this open source game engine that nobody else cared about I felt like, except for like me and like 10 other people, and it was called Syntensity. And it was game engine that was designed for you to extend it live and it was based on JavaScript and stuff. And then he was like, "Well, these things need to compile to the Web". So he started working on how do we get C programs to compile to the Web? And that basically became Emscripten, and he started working at Mozilla. And so in order to have those browser games run on the Web and have them run using a kind of "standard technology", you could compile to JavaScript, but it was too slow to run 3D graphics programs in the browser using JavaScript. So they introduced this hack called ASM.js. And ASM.js did the ugliest things imaginable. You would basically insert these little things that-- if you said "include ASM.js" in a string that would just be ignored. Like a compiler that didn't know about it would ignore all these things, but you could put all these really ugly annotations. And if the compiler knew to look for them, then it would do the smart fast paths for each one of the things that it found. And it was ugly as sin. But one of the people said, "But the brilliant part of it was it forced everyone to have to adopt it". The other browsers didn't want to adopt it. But since you technically could run the programs slowly and other browsers, if you didn't have the ASM.js support, you just made it look like these like fancy games that were being compiled from 3D, like these other browsers somehow had gotten fast enough they could run these 3D games and stuff. And then the other ones just didn't know how to catch up. So they were forced to adopt this and everyone hated it because ASM.js was terrible. And so it forced everyone to come to the table and say, "okay, how do we design the thing that we actually want to support?" And that became WebAssembly.
+C: And then they don't. Nothing better emerges. So there's that. And then the other thing that happened was I was just overhearing these people talking, and they're like, "well, the amazing thing about WebAssembly is the way that it ended up coming from ASM.js". So there was a few years ago, there was a person named Kripkin who Mozilla had hired. He was working on a project that I was really excited about, which was this open source game engine that nobody else cared about I felt, except for me and like 10 other people, and it was called Syntensity. And it was game engine that was designed for you to extend it live and it was based on JavaScript and stuff. And then he was like, "Well, these things need to compile to the Web". So he started working on how do we get C programs to compile to the Web? And that basically became Emscripten, and he started working at Mozilla. And so in order to have those browser games run on the Web and have them run using a kind of "standard technology", you could compile to JavaScript, but it was too slow to run 3D graphics programs in the browser using JavaScript. So they introduced this hack called ASM.js. And ASM.js did the ugliest things imaginable. You would basically insert these little things that-- if you said "include ASM.js" in a string that would just be ignored. A compiler that didn't know about it would ignore all these things, but you could put all these really ugly annotations. And if the compiler knew to look for them, then it would do the smart fast paths for each one of the things that it found. And it was ugly as sin. But one of the people said, "But the brilliant part of it was it forced everyone to have to adopt it". The other browsers didn't want to adopt it. But since you technically could run the programs slowly and other browsers, if you didn't have the ASM.js support, you just made it look like these fancy games that were being compiled from 3D, these other browsers somehow had gotten fast enough they could run these 3D games and stuff. And then the other ones just didn't know how to catch up. So they were forced to adopt this and everyone hated it because ASM.js was terrible. And so it forced everyone to come to the table and say, "okay, how do we design the thing that we actually want to support?" And that became WebAssembly.
 
 M: That's how we create things.
 
@@ -106,7 +106,7 @@ C: "Making things together with the shared trauma of compiler experiences"? Oh,
 
 M: Yeah, that's not--
 
-C: --a good ending. Okay. Wait, wait, wait. Let's end it on a positive note. So I am sure, I'm hoping, over the next year that we can show really exciting things with Spritely's tech with compiling to WebAssembly. One way or another, what I do know is that I think this is going to push things forward in fun and exciting ways. Andy Wingo, who is leading the project, is not only a compiler engineer on V8 and SpiderMonkey, the two top JavaScript engines in the world and also contributes to WebAssembly. He's also the Guile lead maintainer. And by the time this episode is out, we will have announced the new engineer, Robin Templeton, who is a person that we were hiring in-house to continue this work. Robin is awesome. They worked on the Guile Emacs project, which allowed you to actually run Emacs on top of Guile. And it was like a really cool project. They're so incredibly well positioned to be able to make this project happen also. So I'm excited to have them and Andy working together and for them to kind of carry forward that knowledge internally and within Spritely also. And yeah, it's just exciting times ahead. I'm sure, you're listening to this episode now. You have this impression that web assembly is just this thing so that people can have C and Rust programs in the browser. You're wrong. Get ready. WebAssembly everything. It's happening.
+C: --a good ending. Okay. Wait, wait, wait. Let's end it on a positive note. So I am sure, I'm hoping, over the next year that we can show really exciting things with Spritely's tech with compiling to WebAssembly. One way or another, what I do know is that I think this is going to push things forward in fun and exciting ways. Andy Wingo, who is leading the project, is not only a compiler engineer on V8 and SpiderMonkey, the two top JavaScript engines in the world and also contributes to WebAssembly. He's also the Guile lead maintainer. And by the time this episode is out, we will have announced the new engineer, Robin Templeton, who is a person that we were hiring in-house to continue this work. Robin is awesome. They worked on the Guile Emacs project, which allowed you to actually run Emacs on top of Guile. And it was a really cool project. They're so incredibly well positioned to be able to make this project happen also. So I'm excited to have them and Andy working together and for them to kind of carry forward that knowledge internally and within Spritely also. And yeah, it's just exciting times ahead. I'm sure, you're listening to this episode now. You have this impression that web assembly is just this thing so that people can have C and Rust programs in the browser. You're wrong. Get ready. WebAssembly everything. It's happening.
 
 M: Excellent. All right. Thanks everybody.
 
@@ -118,7 +118,7 @@ C: All right. That was going to be the end of the episode, but we've arrived at
 
 M: Yeah. So you've actually made a lot of progress on Hoot since we recorded this episode, you want to talk a little bit about that?
 
-C: Yes. So now Hoot can compile some basic Scheme programs to WebAssembly. And let me clarify, when I mean basic ones, I mean like the factorial function and Fibonacci, not ones doing like a lot of complicated things, more like your "intro to computer science program" ones. But we are clearly on an exciting path because even that is possible right now.
+C: Yes. So now Hoot can compile some basic Scheme programs to WebAssembly. And let me clarify, when I mean basic ones, I mean like the factorial function and Fibonacci, not ones doing a lot of complicated things, more like your "intro to computer science program" ones. But we are clearly on an exciting path because even that is possible right now.
 
 M: Yeah. And also when I say you, I meant you collectively as in Spritely and your team.
 
@@ -126,7 +126,7 @@ C: The Sprightly Institute team. That's right. And I'm not one of the primary pe
 
 M: Yeah. And the Spritely team recently participated in a game jam using Hoot, right?
 
-C: Yeah. We participated in the Lisp Game Jam. We actually did two different things. One was Fantasary. It was like a virtual worlds mini system. And the other one was an implementation of Wireworld, which is a kind of cellular automata. So actually the funny thing is if you remember earlier in this episode when we were talking about how Tristan and I had done the "It WASM Me" kind of "user group of two" doing implementation of WebAssembly by hand, we were working on an implementation of Conway's Game of Life, and we were like, "Oh, well, the main thing that held it up was it was really difficult to translate all these APIs into the browser. And if only we had used this fantasy console called the WASM-4". Well, one of the things about the game jam is we actually used that fantasy console called WASM-4, and we used it to implement Wireworld, which is a different kind of cellular automata than the Conway's Game of Life. But it's kind of neat because it gives these like circuits. It looks like little computer programs. And it's fun. You can try it right in your browser. We'll have a link in the show notes to the blog post about it. And that was primarily Robin Templeton doing the implementation of that. And I helped with some of the graphics and stuff. But the exciting part about it from a technical level was that it was showing off how Hoot has some low level WebAssembly tools. So it has this assembler and disassembler and things like that, which are used by the compiler. They're not normally what we advertise Hoot as being for, right, normally we advertise Hoot as being compiling a scheme program into WebAssembly. This one was like you're writing low level WebAssembly immersed in scheme, which probably to some members in the audience should be very clear and to some, maybe not so clear. You should read the blog post. It's fun. Anyway, but the cool thing is that you can actually try something that is written in Hoot actually live in your browser, and it's kind of fun and interactive.
+C: Yeah. We participated in the Lisp Game Jam. We actually did two different things. One was Fantasary. It was a virtual worlds mini system. And the other one was an implementation of Wireworld, which is a kind of cellular automata. So actually the funny thing is if you remember earlier in this episode when we were talking about how Tristan and I had done the "It WASM Me" kind of "user group of two" doing implementation of WebAssembly by hand, we were working on an implementation of Conway's Game of Life, and we were like, "Oh, well, the main thing that held it up was it was really difficult to translate all these APIs into the browser. And if only we had used this fantasy console called the WASM-4". Well, one of the things about the game jam is we actually used that fantasy console called WASM-4, and we used it to implement Wireworld, which is a different kind of cellular automata than the Conway's Game of Life. But it's kind of neat because it gives these circuits. It looks like little computer programs. And it's fun. You can try it right in your browser. We'll have a link in the show notes to the blog post about it. And that was primarily Robin Templeton doing the implementation of that. And I helped with some of the graphics and stuff. But the exciting part about it from a technical level was that it was showing off how Hoot has some low level WebAssembly tools. So it has this assembler and disassembler and things like that, which are used by the compiler. They're not normally what we advertise Hoot as being for, right, normally we advertise Hoot as being compiling a scheme program into WebAssembly. This one was like, you're writing low level WebAssembly immersed in scheme, which probably to some members in the audience should be very clear and to some, maybe not so clear. You should read the blog post. It's fun. Anyway, but the cool thing is that you can actually try something that is written in Hoot actually live in your browser, and it's kind of fun and interactive.
 
 M: And it looks pretty.