CppCast - Web Assembly

Episode Date: June 11, 2020

Rob and Jason are joined by Ben Smith from Google, chair of the Web Assembly working group. They first discuss a blog post on how to ask for C++ coding help, conference news and a discussion on C++ IDEs and tools. Then Ben talks to them about the current state of Web Assembly, the future and alternative uses for Web Assembly like Virtual Machines and Emulators. News Toml++ v1.3.0 released How to ask for C++ coding help C++ On Sea Updates Huge discussion on C++ IDEs and editing tools Links Web Assembly Wasmtime Wasmer CppCon 2019: Ben Smith "Applied WebAssembly: Compiling and Running C++ in Your Web Browser" A Talk Near the Future of Python (a.k.a., Dave live-codes a WebAssembly Interpreter) Sponsors Clang Power Tools Use code JetBrainsForCppCast during checkout at JetBrains.com for a 25% discount

Episode 251 of CppCast with guest Ben Smith from Google, recorded June 11th, 2020. This episode of CppCast is sponsored by Clang Power Tools, the open-source Visual Studio extension on a mission to bring Clang LLVM magic to C++ developers on Windows. Increase your productivity and automatically modernize your code now. Get ahead of bugs by using LLVM static analyzers and CppCore guidelines checks from the comfort of your IDE. Start today at clangpowertools.com. And by JetBrains, the maker of smart IDEs and tools like IntelliJ, PyCharm, and ReSharper. To help you become a C++ guru, they've got CLion, an intelligent IDE, and ReSharper C++, a smart extension from Visual Studio. Exclusively for CppCast, JetBrains is offering a 25% discount on yearly individual

licenses on both of these C++ tools, which applies to new purchases and renewals alike. Use the coupon code JetBrains for CppCast during checkout at JetBrains.com to take advantage of this deal. In this episode, we discuss how to ask for coding help and C++ tools. Then we talk to Ben Smith, chair of the WebAssembly Working Group. Ben talks to us about the current state of WebAssembly and its future. Welcome to episode 251 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm all right, Rob. How are you doing?

I am doing fine. Don't think there's really too much news to share myself. You, uh, no, like all the public things are on hold basically. Right. So yeah, nothing's really changed on that side. Uh, I will share something that's moderately interesting because we talk about the meetup on our podcast and apparently someone my meetup the denver meetup um someone mentioned my meetup at the munich c++ meetup uh the other day and then we had in our last meetup which we're doing via zoom we had like a couple of people from germany and someone from england now keep in mind we start

at 6 p.m denver time so it's like midnight or something for them right we're starting at midnight no if not later yes we're starting at 2 a.m and we had people from europe joining us and they stayed not only for the talk but also for like an hour of the happy hour after that I was Impressed yeah something. Yes. It was like four o'clock in the morning when they're getting off and then we also had someone from Taiwan Somewhere where it was like seven o'clock in the morning for him when we started Wow So he like we're like, hey, who are you? So he pulls over he was apparently driving pulls over on the side of the road and like turns on the video on his phone so we can like chat with

him for a minute it's interesting the last time i thought about c++ at 4 a.m right okay uh well at the top of your episode i'd like to read a piece of feedback uh we got this long email i'm not gonna read the whole thing but it's uh hello thanks for the people's health center podcast very appreciated i mostly listen to it while ironing my clothes i would like to make a suggestion for episode 300 um which is you know full years away but we appreciate the suggestion instead of the usual suspects uh bjarne, Herb, or Andre, I'd like you to invite Andrew Koenig, who worked with Bjarne at Bell Labs

and did a lot of work kind of in the early days of C++ at Bell Labs. I don't think I've heard his name before, but yeah, I Googled him and he definitely has done a lot of great work for C++. So I should see if he's uh still active and might be interested in coming on i have heard the name before but no i wouldn't be able to give you a lot of details yeah that name is famous for the lookup right isn't that is that

right yeah can i look up oh that's the rules for um argument dependent lookup right yeah i think so okay yeah that sounds right that would definitely be a good suggestion then uh i don't know if we want to wait a whole uh 50 more episodes to have them on but uh i will start looking into it well we'd love to hear your thoughts about the show you can always reach out to us on facebook twitter or email us at feedback at cbs.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Ben Smith. Ben is a software engineer at Google on the WebAssembly team, as well as the chair of

the WebAssembly Working Group. Ben, welcome to the show. Hi, thanks. Yeah, glad to be here. Ben, I believe you win the award for the shortest bio that Rob has ever read. I like to keep it short and sweet, I guess. Mostly I can't think of anything else to say. Well, I get that.

Sometimes you're stuck between too little or too much when you're working on your bio. Maybe we could ask how long you've been working on WebAssembly and what you do at Google before then. Because it is a fairly recent project over the last five or six years, right? Yeah, that's right. Yeah. So I've been basically working on WebAssembly since, I guess, not exactly the beginning, but basically the beginning, 2015. Although we didn't really have a WebAssembly team then. So yeah, for about five years. And I've been at Google since 2011. before that but before that I was working on

Native Client which is a sort of similar-ish technology it was about running C++ in the browser in Chrome by using a sandboxing technology so and then before that I used to work on video games but that feels like very ancient history now any games that we would recognize uh maybe uh there i did a brief period where i was at blizzard where i was working on um the game that became overwatch but at the time it was a very different game so i worked for two years on um on overwatch before it was overwatch so I don't know if that gives me some kind of cred. Do you ever wish you were back in the game development world? You know, I really do love games.

I still play them quite a bit. There are things about that that I really like. Actually, one of the things I really love about the game industry is that you work with a lot of different types of people. So you work with artists, you work with musicians, you work with designers. And that may be less common when you work in sort of straight tech. So I do miss that. But yeah, I like working at Google.

It's pretty great here. That's cool. Okay, well, Ben, we got a couple news articles to discuss. Feel free to comment on any of these, and then we'll start talking more about your work in WebAssembly. Okay, well, Ben, we got a couple news articles to discuss. Feel free to comment on any of these, and then we'll start talking more about your work in WebAssembly. Okay? Sure. All right, so this first one is a library update,

which is Tumul for modern C++, and it's version 1.3. I don't think we've talked about this library before. And I'll be honest, I've interacted with Tumul files somewhat recently because the tool we use to generate the CPCast website has a Tumul configuration file. But that's my only familiarity with it. I don't know too much about Tumul. It seems like kind of a fancy INI file format. I'm wondering, Ben, if you know more about this since you're probably more hooked into web technologies than we are uh i don't know a whole lot about this format other than that it's the format used for like uh rust right for cargo

oh is it yeah i spent a couple minutes staring at this going why am i supposed to care why am i supposed to oh right i've been learning rust recently yeah but yeah otherwise i don't know much about it i mean i think it's supposed to be friendlier than json which isn't very good for this sort of thing and friendlier than ini but but yeah i'm i'm not super tuned into this format for sure well one thing that stood out to me is the project has a JSON outputter. So if you have any reason to go back and forth with some other tool that doesn't have Tumul support, then you've got that. Which, you know, it seems like there are definitely all those cases where you're like, well, let's

see, I've got this configuration data and the other thing uses YAML, but this thing uses JSON. So I don't know, at least we have the parts to connect them together. Yeah. I mean, they're all basically doing the same thing, right? All right. Next thing we have is an article on Kate Gregory's blog, and it's a pretty long post, but I thought it was a good one. And it was how to ask for C++ coding help. And it's a pretty long post, but I thought it was a good one. And it was how to ask for C++ coding help. And it's basically Kate's thoughts on, you know, having people approach her in online communities and how to go about asking help the right way. Definitely some good stuff. She points to Stack Overflow as a pretty good community for requesting help.

I am bookmarking this article. I am using it when I get questions for help from people because it's more than just, oh, you could ask Stack Overflow. It's all these like, don't paste a screenshot of your code. Send us a Godbolt link or a wand box link like oh my goodness the number of people like on c++ reddit that paste screenshots of what they're trying to do that is very difficult to give help when people do that yeah it's a good article i really liked it yeah i thought it was pretty interesting too, for sure. I definitely saw

sort of similarities to when I was working with students last year. It's very helpful to have the mask in the right way. Although it's different when it's like in person versus online. Right. Okay, next thing we have is an update on talks and speakers at the CPP on C talk. And this is pretty good. They, uh, are now going to have Herb Sutter and Walter Brown as keynotes, which is pretty cool.

Um, and this conference is moving fully online, right, Jason? Yeah. Yeah. It's fully online. The tickets are available now.

I think they're, where's the price? If either one of you have it off the top of your head, it's worth it. Uh, full online conference 125 pounds so not i mean way cheaper than an in-person conference would be right they're still doing the workshops too if you're interested in those looks like they are still doing the workshops yeah

yeah i read through some of the uh the topics it looked like there's some good stuff i'm pretty interested in uh c++20 stuff for sure. And ranges always sounds cool, although I haven't used them yet. That's approximately where I am with ranges too. I'm tempted to sign up even though the time zones would be all wrong, mostly just to see how this goes, the fully online conference yeah are they still gonna split it up into different tracks with you know multiple tracks giving their you know talks at the same time or could you actually maybe see more of the content in an online format i wonder i have no idea yeah be curious to see hmm at least you won't have to be too late to the room and miss getting a seat.

Yeah. Okay. And then, Jason, you put one more link here about a Reddit discussion about what IDEs C++ developers are using. I thought it was apropos because someone had just asked me on Twitter at approximately the same time what my favorite IDE was. So I retweeted it, and there's been a large Twitter discussion about that and simultaneously, but I think they were two different people. Someone posted to Reddit

asking what IDE do you use? And there's just a ton of info in here. I'm not even going to go through any of it. A lot of it's usual suspects for like sea lion and stuff, but you know, there are people who use Emacs, whatever that's about. Ben, what's your tool of choice these days uh you know i used to use visual studio back in the day it was very very common in the game industry and then as soon as i came to google uh they kind of were like okay well you have to pick your side are you vim or emacs and i was like well i don't know i've never used either one and so i just sort of randomly chose vim and i've yeah i've been a zealot ever since so i actually when i first started programming c++ my mentor was using uh emacs and i was faced with this decision like oh

no i have to choose one right and i realized that vi some version of vi is required as part of the unix standard it's going to be on any unix system and i'm like well there's my answer i need to learn how to use vi so now that's my official answer if anyone asks me why i chose it it's because it was purely pragmatic so well and the the keyboard shortcuts show up everywhere right like if you use uh gmail the uh jk um navigation is is built in and and even in github actually they use jk navigation that's just like just like them right so i don't huh okay well ben uh as we mentioned already or as you mentioned uh when we're talking about bio, WebAssembly has been around since about 2015, or at least that's when it maybe started coming out. I think around that time, we had JF Bastion on when it was a very early proposal.

What's the state of WebAssembly today, though? Yeah, that's a great question. So actually, I did a little digging, and I found that you chatted about WebAssembly in 2018 as well. Yeah, we had Damien Boole on a while ago. Right. Yeah. And so those are actually kind of two interesting points, right? So 2015 was when it basically started. There was nothing and then there was WebAssembly. But I'm guessing by the time that JF was chatting with you, it was still not really

fully formed. We didn't ship in browsers until about 2017. And then by 2018, people were sort of like, okay, what is this thing? Seems kind of cool, but there wasn't a whole lot of usage yet. And now I think what we're seeing is a lot of excitement about it. So some of the big news stories were that last year in December, we had the version one standard become an official standard, a W3 standard. So you can look at the spec now up on W3.org. And that has 140 pages of beautiful, beautiful spec text that you can read all the all the details. But since then, we've also had a few new proposals merged in. So we have a proposal process for adding features to WebAssembly. It's modeled after the TC39 process of JavaScript. So it works similarly to that. And the idea is that

as features sort of progress through the standard, eventually they're standardized. They get to phase five and then they get merged into the spec. And then occasionally we will push that spec up to the W3 as well. And so we've already had three new proposals added in. They're pretty minor things, but we're hoping to have some bigger features added in soon as well. So the features happen to be sign extension. So we have some new instructions for sign extension. Seems pretty minor, but they can be useful.

Non-trapping float to int, which is actually an interesting mismatch between C++ and WebAssembly. So the idea here is when you convert from a float to an int, we originally had the behavior that if the float was out of range, it would trap, basically halt WebAssembly execution. And it turns out that LLVM generated code that ends up being tricky because they sort of expect, based on most hardware architectures, that when you convert, it does sort of a best effort instead of trapping. So then they have to do an initial check beforehand to prevent it. Anyway, so sort of delving into the details here, but adding a non-trapping version of that conversion means that now we can have faster execution for that common operation. Oh, there's definitely people listening

to this podcast who would find that interesting, just the record so feel free to go into the weeds on some of those things okay excellent and then um another one that we implemented was multi-value and so that's another um interesting case if i can get into little details um so web assembly is a stack machine and so um certain things about a stack machine make it very easy to to handle multiple values, right? Normally, programming languages, you accept multiple parameters and you return one result. You might return multiple results as a tuple or something. But in a stack-based language, it's actually very convenient to just leave extra values on the stack, right? And then that's how you would handle multiple returns.

And so WebAssembly was sort of already set up for this. And it turns out that that actually is beneficial in a number of ways for, say, in C++, if you want to have struct returned on the stack, you could actually return multiple values instead of having to write into memory and then read back out. So we can actually lower to a more efficient form in WebAssembly. So that's kind of a cool, useful feature that we've recently added as well. So yeah, so that's kind of the current status inside the sort of core of WebAssembly, which is what I focus on. But then outside of WebAssembly, there's a lot of stuff going on too. So originally we focused WebAssembly on this idea of being a web-based execution engine, right? It's just sort of like alongside JavaScript. It's another place you can run code. But it turns out that a lot of the design

that we did around WebAssembly makes it very useful for a lot of other environments as well. So if you think of something like Lua, why are there so few languages that are so nice to embed inside of other environments. Blue is probably the most common one. And I think WebAssembly sort of fills a similar role, but as a VM, where it's very easy to embed because we designed it as being an embeddable VM, right? It's designed to be embedded inside the web platform. And so for any other platform that wants to have a portable execution environment, WebAssembly is a really great choice, right? So what we see is that

if you are running, say, code on the blockchain, you care about very similar things, right? You care about the security, you care about non-determinism. And so rather than defining your own environment, you can create, you can use WebAssembly as a basis. So, and then the security properties that we care about for the web also matter for WebAssembly. So if you care about those security properties running natively, then WebAssembly is a good choice. So anyway, that's sort of the sum of the state. I don't know if you have some questions. Now, I am finding myself extraordinarily curious at the moment of just how easy it is to write a WebAssembly VM then. So like, do there currently exist very easy to use portable embeddable

VMs that you're recommending people use? Or are you saying, well, it's so easy to embed, you can just slap together your own VM real quick? I mean, so yes and yes, actually. There are some really great ones. And also, it's kind of a fun, I mean, in my opinion a weekend or multiple weekend project to create your own in fact there's a great great great talk um by i'm gonna forget his name now i think it's dan beasley uh where he implemented a web assembly engine during his talk in python and took some code that was um compiled by rust toAssembly that was like a little spaceship

shooter game and got it working by the end of the talk. So it's not too hard to get working. The number of instructions is pretty low. I think it's like 80 total, but most programs don't use them all. And yeah, so you can do it yourself. I've actually written a WebAssembly interpreter that we maintain and people use. But realistically, you're going to want to use one of the professional ones. And there's actually quite a few of those, too.

They're basically in all the web browsers. But then also there are some standalone versions like Wasmr and WasmTime and Wasm3 and Wavum. Anyway, they all start with wa, so they're going to be hard to distinguish. But yeah, there's quite a few of them, and they all have sort of different properties depending on what kind of things you want out of a WebAssembly engine. So just now to go backward, though, if people are interested in at least understanding the spec or writing their own interpreter, how do you find that information? Yeah, so some people kind of like to do this, like you're writing an emulator or something.

And so in that case, you can just pull up the spec and go to town. It's a little bit tricky. I've heard that the spec is hard to read. It's actually very mathematical. It's been formally verified, so you know it works. But yeah, it can be pretty dense. Actually, if you're really curious about floating point semantics, WebAssembly, as far as I know, has some of the most sort of formalized semantics of the IEEE floating point math. So if you want to look at the execution semantics there, they're pretty cool. But yeah, the spec is a good place. But also, you could just look at some of the tests that we have. You can also sort of cheat and use some existing interpreters. And then there's some sort of like easier documents. So back when we were designing WebAssembly, we had a document on GitHub called WebAssembly

slash design. It was the design repo. And if you look at the semantics and binary format documents there, they have some of the sort of early documents that we were using that are sort of simpler to read. They're not up to date. We haven't been keeping them up to date, but they are some good opportunities to get your feet wet writing some WebAssembly.

Sorry, it does sound like it would be a lot of fun, so I won't dwell on it too much. But it's interesting that you said that the spec has been formally verified. We had someone on talking about formal verification techniques, what, a couple years ago, Rob? Something like that? Yeah, it's been interesting that you said that the spec has been formally verified. We had someone on talking about formal verification techniques, what a couple of years ago, Rob, something like that. It's been a while.

I'm really curious. Like if you know what tools were used or was there tools used or how that process went? Yeah, I do know. And I'm going to be embarrassed to forget the details. yeah, I just run this on you. So, so yeah so it was um uh so andreas

rossberg is the editor of the spec and i believe he was working with conrad watt conrad watt of um again a university that i'm going to forget in the uk um anyway yeah no i probably should have been prepared we're prepared for this but i I'm, I believe he was the one, um, who, uh, was working on the formal verification. Um, I can probably pull it up if I look real quick, but Conrad Watt is at Cambridge. Yep. Okay. That sounds right. Um, and yeah, he has articles about WebAssembly and verification. Yeah. So that would be it. Okay. I can put a link to that in the show notes if listeners are interested in reading more about it.

Yeah, that's probably the best way. Yeah. But yeah, I don't remember the tool. That's fine. Yeah. Like I said, I just sprung it on you. So you gave a CPCon talk last year where you went over a lot of this,

and I should definitely encourage listeners to go and watch your talk if you haven't already um and one of the things you talked briefly about there that I don't think we talked about with either Damien or JF is the web assembly system interface I was wondering if you could tell us a little bit about that yeah I think I uh I was uh sort of throwing a lot of content into that CPP con talk because I was like, 90 minutes, how am I going to fill this? And so, yeah, I think I probably glossed over a lot of things. But yeah, Wazi WebAssembly system interface is sort of this new design. So like I was saying earlier, WebAssembly itself is this sort of container, right? You can import functionality from the outside, and then you can export functionality back out.

And then it has everything else that's sort of encapsulated, right? There's memory that you can write to, there's variables you can store and so on, and functions you can implement. But otherwise, it can't really do anything. If you think about it, it's very, like I said, very similar to Lua, right? Lua doesn't have a lot of built-in functionality. And so if you actually want really do anything. If you think about it, it's very, like I said, very similar to Lua, right? Lua doesn't have a lot of built-in functionality. And so if you actually want to do anything, then you need to have some API on the outside

that actually provides you that functionality. And so WebAssembly is the same way. And normally, or sort of originally what we said is, well, just come up with your own. It's fine. That's sort of the whole point here. But at some point people say, well, if we're running in a non-web environment, there's certain things that I expect to have. Like, mostly people want to be able to do, you know, a printf or a cout or something,

right? So having some kind of well-defined interface is important there. So that's what Wazy is. It's a standardized interface that's meant to be used by WebAssembly applications for common POSIX-y type stuff. So opening and reading files, directories, sockets, random numbers, and so on. And so then the idea is that as we move forward, we can start to add new features to that as well. So crypto, and graphics and sounds and so on. But starting off, it's going to be sort of the thin stuff that you would expect from 1970s computer.

So if I, at the moment were to use the C++ standard library with WebAssembly and ask for a crypto device, we just talked with Martin about this, right? Like a couple of weeks ago. Would I then be getting actually this crypto device that is hooked in through the system API thing? Yeah, so it's a little bit tricky because depending on the type of WebAssembly you use, you might get something different. Okay. So WebAssembly on the web is going to use the web APIs because WebAssembly, I mean, that's part of the reason WebAssembly doesn't have any built-in functionality. It's because we expected that people would always just use web APIs. So web already has a crypto interface. It's called WebCrypto. And so you can access that directly by calling through JavaScript. But on the non-web environment, there's not really anything there. So having a unified interface is what you would use. And I think they're still

working on it, but yeah, you would get some suite of APIs and some data structures that would go along with that, that will allow you to say, get random bytes and then, or use certain encryption schemes, that kind of thing. So when I implement my own web assembly interpreter, I'm going to need to implement these system calls for myself because the system interface will be expecting them. Yes. Again, sort of depending on the WebAssembly. Right. So, yeah, I mean, I think I've seen you that you have done some emulator stuff before. Yeah, I have. But, you know, let's not pretend like I really know what I'm doing. It's just something that is fun for me every now and then. Yeah. So one of the cool things about WebAssembly and one of the hard things, too, is that if you just take a random

WebAssembly file, there's a good chance that you won't be able to run it 100 percent. Right. Because it'll it'll say I'm importing things like GL graphics. And so you'll have to sort of know what they expect from that. The WebAssembly interface is hoping to make that more unified. But for now, it's very common that people will compile using Emscripten, which is a C++2 WebAssembly compiler. And so that has its own set of APIs that will have different behaviors. So if you know what the JavaScript is going to do, then you can implement it yourself in your WebAssembly interpreter. But the hope is that eventually we'll get to a place where there's just the spec and you say, yep, here's the functionality I need, and then you implement that.

So what will happen right now is you'll take a WebAssembly file that you're interested in running, and then you'll hit some import and you're like well what does this do and then you have to go and figure it out just like if you're writing an emulator right right so like right now my emulator can only play tetris but next week it'll be playing super mario brothers exactly hey you know we just had people ask us to cover more um emulator talk rob so I'll just phrase the rest of the questions in this interview in context of that. Yeah. So actually, I wrote a Game Boy emulator in WebAssembly.

So I'm definitely happy to talk about emulator stuff. So have you been able to run it on your own WebAssembly interpreter that you are maintaining? That is false. been able to run it on your own web assembly interpreter that you are maintaining that is i know this sounds dumb but i never even thought to do that that's like full end to end right like yeah you've you've got to try that let us know how it works yeah no that's that's a good point i really should try that so did you write your when you say you wrote your gameboy emulator in this web assembly did you did you actually hand code it in web assembly or do you use rust or c++ or something and then compile yeah so i i used c actually because i was on a bit of a c kick at the time

and um and it actually turns out that it compiles really really well to to web assembly you um you can actually set up like extern functions. And there's better ways to do this now. But if you just call out to an extern function, then when you compile the module, it'll sort of say, well, I don't know what this is. So I'm assuming that you'll fill it in later. And then you fill it in with a JavaScript function. And then when you call out, it just calls to whatever JavaScript functionality you need, like drawing pixels or so on. So you get this nice sort of capsule of code, and then you just sort of wire it up to the web browser, and it's ready to go.

But like I said, it's way easier to do nowadays. I think you can actually embed JavaScript directly in your C++, and then the compiler will sort of extract it for you and then wire it up. So there's some cool stuff. And then actually Rust allows you to do the same thing, but that's, I guess, for a different podcast. Since you mentioned other languages, we can just briefly talk about this. I think JF said that C++ was kind of the first language

that WebAssembly was built for, but is any compiled language capable of writing to WebAssembly? I won't go so far, but is any compiled language, you know, capable of writing to WebAssembly or targeting? I won't go so far as to say any compiled language, but definitely that's a goal is to support as many languages as we can. So C++ was sort of our starting language just because we were like, well, this is a use case that we know we already have. People are currently compiling C++ to JavaScript, which is what was happening at the time. And yeah, exactly. And one of the issues we were having is that as JavaScript VM implementers, we had to deal with this really bizarre code, right? This code that no one would write by hand. So WebAssembly was meant to be a way to say, okay, instead of

doing this, which is sort of a roundabout way, why don't you compile to something that we want you to compile to? And now we can sort of deal with that. So that was the reason we started with C++. But then because we were using LLVM as a backend, then most languages that use LLVM to generate their native code could also use LLVM to generate WebAssembly. So that means we get, I won't say for free, but Rust support comes along for the ride, as well as things like Zig can compile to WebAssembly, if you've heard of that. It's kind of an interesting newish language. But also languages like Go doesn't use LLVM, but that's been coming along. Some people have put some effort into that.

There's a language called AssemblyScript, which isn't a language sort of before WebAssembly, but was developed to be sort of like a TypeScript-like language that compiles to WebAssembly. Some people have been working on OCaml engines and on Haskell implementations and C-sharp. So actually, one really common case is, or one thing we've been seeing a lot of is this product called Blazor from Microsoft that actually is meant to be sort of a full environment where you can take C sharp and compile that and then also sort of create web apps using sort of

your normal Visual Studio tools. So yeah, we're starting to see a lot more languages compiled to WebAssembly. They're still not necessarily fully featured, but they're coming along. And I think as WebAssembly gets more functionality, the number of languages we're going to be able to support will increase. I'm also curious, since you said it's designed for embedding and whatever, and you just mentioned all these languages that are starting to support it. If there's a language hobbyist that says, okay, I'm making my own toy language and I want to actually compile it, would you recommend that compiling to WebAssembly would be a good exercise

instead of into native machine hardware? I think it would be an interesting exercise for sure. Yeah, so WebAssembly is a little weird compared to most uh native targets so um the biggest difference and i think the the thing we get the most complaints about is that web assembly requires structured control flow so we don't have just go-to's in web assembly and that was by design and so instead what we have is two different types of instruction. We have a loop instruction where there's a loop at the top and a branch. And whenever you branch to that loop, you go to the top.

So it's basically a backwards branch. And then we have a block instruction which branches to the end. So that's a forward branch. And so you have to actually nest all your code. And that has some nice properties. But what that also means is that if you're used to being able to just drop in a go-to, you won't be able to do that. And that can be tricky for some environments.

But there are tools to make that a little bit easier. A lot of people use this tool called Binarian, which is a, I think it was a play on the name Targaryen, the Game of Thrones. No, from Game of Thrones. Okay. Right. But anyway, the point of that tool is that it's got a number of WebAssembly features, one of which is that you can write sort of normal code that has branches, and it will convert it into a blocky format it it uh the

feature is called re-looping so it basically turns those things into loops i don't know it kind of sounds like it takes some of the fun out of it though because half of the fun and like writing assembly language or something is you know working within the restrictions of that processor and well yeah no i i agree with you but you know if you're just supporting if you're just trying to support something maybe you don't want to you know go on a deep dive into intricacies of web assembly i also found it interesting because i've recently been reviewing basic just out of you know my own because it's like the first five programming languages that i used were basic dialects and what you just described sounds like it's perfectly structured

for a basic interpreter because you have a four and then a next which jumps you back up to the top and otherwise you don't have very complicated control flow um now most basic interpreters would have go to but you could just leave that out of your version of basic and just roll with it. Yeah, you could. And actually, we see a lot of that where people, there's sort of two choices, right? The easy choice is to write in an interpreter that runs on WebAssembly, right? So it actually reads the instructions of your language and then implements those in WebAssembly. And that has the drawback of being slow. And so then the next thing that usually people do is they take that code and then they actually try and generate WebAssembly instructions.

So what you're describing is more like a basic compiler for WebAssembly, but yeah, you, yeah, it shouldn't be too, too hard to do, you know, too hard.

I'll just add all this to the next, you know, on top of my 15 projects that i'm already working on and i want to interrupt the discussion for just a moment to bring you a word from our sponsors clang power tools is the open source visual studio extension on a mission to bring lvm tools like clang plus plus clang tidy and clang format to c++ developers on windows increase your productivity and modernize your C++ code with automatic code transformations powered by Clang Tidy.

Find subtle latent bugs by using LLVM Static Analyzer and CPP Core Guidelines checks. Don't fiddle with command line switches or learn hundreds of compiler flags. Clang Power Tools comes with a powerful user interface to help you manage the complexity directly from the comfort of your IDE. Never miss a potential issue by integrating

Clang Power Tools into your workflows with a configurable PowerShell script for CI-CD automation. Start experimenting on your code today. Check it out at clangpowertools.com. Okay, so you mentioned that there's a WebAssembly working group that you're the chair of. Do you know much about, or can you tell us much about what the future of WebAssembly is,

like upcoming features we might be able to expect yeah so um there's a bunch of new stuff that we're working on now that i'm really excited about um one of the biggest ones is actually connected to what we just talked about which is um garbage uh garbage collection which is supporting new languages so um right now we have essentially what's what we call sort of the linear memory model which maps very well to things like c++ so the idea is um you basically get this big block of memory and you just write data in and you read data out and the big block of memory is just it's just bytes it means nothing to web assembly it's it's all entirely user control, right?

But that doesn't actually work very well for languages like, you know, well, any sort of language with a garbage collector because what they want is sort of managed objects. And so what they end up doing a lot of times now is they implement their own garbage collector in that memory space, right? So you walk over the memory and then you know which things exist and you free them or whatever. The problem with that is that it's slow because you sort of have to reimplement a lot of functionality that already exists. And another problem with that is that

because WebAssembly is meant to be embedded inside of something else, often the host has its own idea of objects that you want to have communicate with WebAssembly. And so now you have this sort of cross GC problem, right? If I'm holding onto a host object and the host object is holding onto one of my objects, and then that object is holding onto a host object and so on. Now you have this sort of, how do I collect across GCs, garbage collectors? So the idea of the GC proposal is to sort of hand the responsibility of garbage collecting over to the host and say, you deal with it.

So I'm going to ask you to create an object and then you deal with the lifetimes. And here's the sort of shape of it. So that's something that we've been working on for a long time. And as you can imagine, would be very hard to support in a language like WebAssembly because we want it to be so generic and support a lot of different programming languages. But yeah, I think we're making good progress there. Some other exciting features are SIM, um, that's actually very, very close. Uh, you can already use that in, um, some browsers if you flip a flag and soon we'll probably have that,

um, on the open web. And, um, people are very excited about that because that means now you can take your WebAssembly program and do all sorts of video processing, audio processing, and so on. Um, and so that's a pretty exciting feature for a lot of people. The tricky part there, again, is sort of finding the right subset of instructions that map very well to various native architectures, because the whole point is that we don't want to provide functionality that would be complicated to map to SSE, for example. Threads already sort of exists on the web, so you can already use threads in WebAssembly,

but it's sort of limited, so it would be great to see some progress there. So that's some future of WebAssembly. And then Interop is another sort of big case that we want to work on. So right now, WebAssembly can talk to JavaScript, and it sort of works, but it's a little bit of a hard line, because right now, WebAssembly only knows about numbers, it knows about integers and floats. And JavaScript has this sort of full suite of ways it wants to communicate, right?

Objects and strings and arrays and so on. And so we want to come up with a way to have it so that WebAssembly knows how to communicate with the host in sort of a more expressive way. And so we have a feature called interface types, which is we're working on that allows you to sort of express these higher concepts inside of WebAssembly. So those are some of the things that sort of features that we're adding to WebAssembly. But ultimately, the future, I think, for WebAssembly is WebAssembly everywhere. I guess that's kind of my manifesto is sort of like WebAssembly, I think, is sort of universally interesting. There's a lot of different places you can use it. And what I want to see is that people start using it everywhere where it's possible.

Anywhere you need portable execution, anywhere you need a secure environment to run, anywhere you want to embed some code. If you were thinking, I want to embed this programming language, well, why embed one programming language when you can embed a VM that allows you to embed a lot of different programming languages. So, um, and then on the flip side, if I want to run an application and I want it to work on the web, well, why not use WebAssembly? Like it should be the obvious choice. So that's the place where I want to get to is where WebAssembly sort of exists on the server, on the client, IoT, everywhere. Are you starting to see much movement in that space? Like, are you starting to see web developers become more interested in WebAssembly as an option on top of, you know,

JavaScript, which has been their default for a long time, I guess? A little bit, yeah. I think it's still new. I mean, the web moves kind of slow. And also there's a lot of things that JavaScript is just better at. If you're making your standard sort of web app, JavaScript is a great language for it. I think what happens is you start to hit the seams, the places where JavaScript stops being as powerful or it doesn't do exactly what you want, or maybe there's a little

performance concern there. And that's where WebAssembly can step in and often bridge the gap. But the place where I think I'd like to get to is where you can write more and more of your application in WebAssembly and it works. And for some cases, that's actually already possible. Like I said, there's a really awesome Blazor demo where they show off writing your web app in C Sharp. And Rust has some really great tools there too for being able to communicate directly with the web environment fully inside of a Rust program.

So yeah, I think we're not seeing it yet, but give it time. Okay. I'm definitely seeing this, the WebAssembly everywhere that you just mentioned. It makes a lot of sense to people that, like game developers who need a fast execution environment for their scripts.

They could write their scripts in a language like C++ that has awesome optimizers available for it and use that or they could write it in their own homebrewed scripting engine like many of them already do or whatever if someone wrote a lua compiler that went to web assembly then they could already you know like leverage all these things in one place. Yep. You know, in the 45 minutes we've been chatting, I feel like I'm on board. I just, like I said, I don't have the time to explore all these things. So when is the interpreter coming?

I want to see this WebAssembly engine you're making. I don't know. You said someone did it in a live talk, right? Yep. I feel a challenge to do it on a live stream and see what happens, but I don't know. We'll see. No promises to anyone. Take a look. Actually, yeah. So one of the things that I do as sort of a fun little

WebAssembly challenge is I've been making these things I call raw WASM. So mostly WASM is meant to be, you know, you start with a source language and you compile it and you end up with some Web Assembly code, but you can write it by hand. It's kind of a pain. And so what I've been doing is writing these tiny little programs in WebAssembly directly and trying to get them as small as possible. So I've made a few things. I made a little Wolfenstein-like maze game and I made a little ray tracer in like a thousand bytes or so and um i actually was just working on a chip 8 emulator um and i got that in about thousand bytes so that's a fun little thing uh that you can sort of take and use that as an example for your uh web assembly

engine when you your chip 8 emulator yeah exactly stack all the emulators emulate all the okay uh i'm just gonna do a quick search for that so that it's ready to go um so is that does anyone written an assembler for web assembly then or are you like handwriting what does it what does it look like is it you know i'm assuming it's byte code of some sort. It is a bytecode, yeah. So we have a text format and a binary format. The text format is a little clunky. It's S expressions. And it's, yeah, it's hard to write. So for example, anytime you want to refer to a number, like a 32-bit number, you have to actually write out open paren, i32..const 0, close paren. And that would be the number 0, because that basically pushes that number onto the stack.

So yeah, it's very verbose. But there are sort of other formats that are lighter, but they're sort of non-official. So yeah, the actual text format is pretty hard to write, I have to admit. Okay. So we spent a lot of time on this show talking about, you know, what's going into the next version of C++, talking to various committee members. As the chair of the WebAssembly group, do you have any thoughts on what C++ could do differently with our standardization? Or what we could learn from WebAssembly? Yeah, so actually, so as far as the process, I don't know.

I feel like you all have that down pretty well as far as coming out with new versions. In fact, the whole sort of three-year cycle thing I think works really well. So I think we probably could have a lot to learn from you all in terms of process. But in terms of some functionality in WebAssembly, some things that we're working on now, we don't really know how to fit it into C++. And so we've been sort of thinking about it. So I mentioned before that WebAssembly has this idea of a block of memory, right? But you don't have just one block of memory. You can actually have 10 blocks of memory individually, and you can index them statically.

And there are reasons you might want to do that, right? So imagine that, again, you're in this host environment. I want my block of memory, which is internal for me, and no one else can look at it. But then the host has its block of memory that it gives to me and says, fill in some data. Now I have two blocks of memory, right? And those things are independent. And I should know when I'm writing into one and writing into the other. But C++ doesn't really have this concept, right? It's just one big linear block of memory. And not only that, but anything you hand to C++, you can scribble anywhere, right? I mean, it's undefined behavior, but there's nothing protecting you from scribbling somewhere you shouldn't.

And so that's an interesting thing that we're like, well, how would you do that in C++? How would you create an opaque pointer in C++? So that's one thing that we're seeing. Yeah, and actually sort of on a related point, the host can hand in functionality to me, right? So imagine that you have a web DOM node, right? It represents a text box. You can hand that into WebAssembly and WebAssembly is going to say, I don't know what this is. It's completely opaque to me, but it can sort of hand it around and it can put it in and store it somewhere. And then it can hand it back out and

say, well, you gave me this thing here, here, have it back. But again, there's no way to do that in C++ as far as I know to have, I mean, void pointer is about as close as you can get, but even a void pointer, you can sort of mess with, right? So yeah, there's things there that we're not exactly sure how they would map to C++. Do you have any other languages that can target WebAssembly? Are they going to be able to implement these features more easily? That's a good question. Maybe not.

Maybe not. This might be a place where we have to have some sort of future language that knows how to support some of these pieces of functionality. But actually, even multi-value is a case that maybe doesn't fit super well with C++, right? This idea of returning multiple values. You can kind of do it, like you say, returning a struct or something, but that's more of an ABI concern. So there's questions there. Or even things like, you know, when we add garbage collection, does that make sense at all for C++? Maybe not. So yeah, the other languages that could support it, maybe as a secondary tool on top of the language, right? So that language would generate some code, and as a secondary tool on top of the language, right? So that language would generate some code, and then a secondary tool would say, well,

you said this, but what you meant was this, and convert it into something else that uses this WebAssembly feature. So another one which I'm a little bit curious about, I don't know the specifics of, we've been talking a lot about coroutines in WebAssembly, this idea of being able to sort of pause execution of a WebAssembly thread and then switch to something else. This is really important in the web because everything is asynchronous, right? So we want to be able to sort of pause execution and then fetch a resource from the network and then resume with that resource available. And I know C++20 has support for coroutines, but I'm not sure enough about what kind of coroutine that is to know whether or not the functionality that we're talking about providing, which is actually sort of like a stack switching type of coroutine, is the type of functionality that C++ is suggesting, which

I thought might be more of like a program rewriting style coroutine. So that might be another feature. Yeah, I think it's not the same type of coroutine. I am so fuzzy on these things. But technically, C++ coroutines require a heap. They're dynamically allocated to things, although that can go away with LLVM's heap elision or Clang's heap elision, but yeah. Okay, so that actually might line up pretty well then. Okay, I have no idea.

It's one of those topics I keep meaning to learn more about. I mean, the people who are into them are very into them so i think there must be something there right okay well we've talked a lot about web assembly uh one more thing i wanted to ask you about that you mentioned in your talk was that uh you did an intro to c++ class as part of google and residence i was wondering how that experience was for you teaching uh Intro to C++ class as part of Google in Residence. I was just wondering how that experience was for you, teaching Intro to C++. Yeah, it was very interesting. Both of you have taught C++ before, is that right? Jason.

I have. I try to stick to classes where people already know C++ and I'm helping them refine their skills. And I could see why that would be beneficial. Yeah, one of the things I... No, I mean, it was an awesome experience, but C++ is a very hard language to start with. And I can see some of the benefits.

It's very nice to be able to sort of talk about things. Like I had an opportunity to talk about floating point representation with these students, which I think kind of blew their minds. I know it would have blown my mind if I was a first-year student. But there are a lot of concepts that I have to sort of hand wave away that are a little too complicated. One thing that I did find, which I really liked liked about c++ and i don't know that a lot of other languages do this um so let me roll back a second so i we we go out as a cohort to a bunch of different schools right a bunch of us and um some of the schools we basically teach whatever the school is already teaching so i taught c++ because Morehouse teaches C++. But some schools teach Python,

some schools teach Java, so on. And so I talked to all these other professors about what their experience is like. And what I found was that they have to start talking about references and ownership earlier because these languages have this transparent concept of references, right? So if you have an int in Java, that's a value type. But if you have a string, it's a reference type, even though it doesn't look different. And Python's the same way, right? I mean, technically, everything is a reference, but some things, it doesn't matter that it's a reference because it's a value, right? And so they have to start explaining this idea of like well, I said a equals B and then I changed a why does B change?

right and In C++ you have this nice property, which is if you just skip the ampersand and pointers everywhere Then everything is a value type, you know, mostly, right? And so it's kind of this nice, nice thing to be able to just say, you're always getting a new copy whenever you use a use something. And, and I actually found that to be maybe the only thing that was simpler about C++ than, than other languages. Okay, very cool. Well, it's been great having you on the show today, Ben. Yeah, it's been great being here. Thanks for coming on.

Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com.

We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.