BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Panel: WebAssembly - the Past, Present and Future

Panel: WebAssembly - the Past, Present and Future

Bookmarks
43:33

Summary

Aaron Turner, Taylor Thomas and Matt Butcher discuss the past, the present, and the future; where they think this technology will be most impactful in the coming years.

Bio

Aaron Turner is Senior Software Engineer @Fastly. Taylor Thomas is Senior Software Engineer @Microsoft. Matt Butcheri is Principal Software Developer @Microsoft.

About the conference

QCon Plus is a virtual conference for senior software engineers and architects that covers the trends, best practices, and solutions leveraged by the world's most innovative software organizations.

Transcript

Eberhardt: For the three of you, what attracted you to WebAssembly? How did you find WebAssembly in the past? If you'd like to introduce yourself, and how did you get into WebAssembly?

Turner: I am Aaron Turner. I'm on the AssemblyScript team, which is a TypeScript like language to WebAssembly. I'm also a Senior Software Engineer at Fastly on the WebAssembly team there. How I got into WebAssembly? I got into it, because I had a frontend JavaScript background, I was building a lot of web apps and things. Then when WebAssembly announced, I was like, I think this can be a really cool technology in terms of unlocking some of the power that we don't really have access to when we're using an interpreted language inside the browser. I saw that. I also thought it was a great way to start bringing some applications to lower end devices and things, and maybe users that don't have great bandwidth or devices to run applications on. I really just got involved. I was watching it. Then when it finally hit stable on all browsers, I started playing around with it. I built a few projects here and there, and just started getting involved in the open source WebAssembly scene with the whole AssemblyScript thing.

Thomas: I've worked in the container and Kubernetes space for a very long time. If any of you here are familiar with Docker and Kubernetes, I've been involved with Kubernetes since Kubernetes 1.2, and Docker 0.6 or 0.7. I'm very old in container years. I came from that background of writing a lot of cloud technologies, and then stumbled upon Rust, because a lot of people on my team were checking that out. Rust and WebAssembly are best of friends. I came into WebAssembly through that way, and really Krustlet was the thing that got me going. I've been working on Krustlet basically, since the beginning. Matt did all the initial work, and then I took it and just ran with it from there with a couple other people from the community and on my team at work. That's where I got into WebAssembly. I'm very involved since then just doing all sorts of random things and beating my head against reverse engineering Kubernetes, and figuring out WASI, and all those kinds of things. That's where I got into WebAssembly at.

Eberhardt: Is that a little bit more recent? I know Aaron, you mentioned you started looking at it back in the day when WebAssembly was true to its name, it was initially a web technology. Taylor, is this slightly more recent, is this in the past couple of years?

Thomas: Yes. I think it was, I call it 1 BC, Before Coronavirus. It's just when we started the Krustlet project, towards the end of 2019. That's really where I got into WebAssembly. It's been a lot shorter time. It's just been about a year and a half.

Butcher: I had looked at asm.js, which I think that was the precursor to WebAssembly. I had looked at that years ago, and read the articles and looked at a bunch of things. I got really excited about it for about two minutes, and then completely forgot about it until it must have been early 2019, when I was on a walk around Boulder doing a one on one with one of my team members. We got to talking about, wouldn't it be cool if instead of using a container, we had this reduced instruction set, and we could compile. We started talking about, yes, there was this thing called asm.js, I wonder what happened to it? Then found WebAssembly, and went, of course. Yes, it was only a couple of years ago now that I really got involved. By that time, Aaron and the AssemblyScript team had already done some releases. It was a great time to jump in, because a lot of the foundations had been laid already. We could jump in and just tackle the problem that we had at hand at the time, which was, how could we use it in the cloud. How could we use a technology that was hardened for the browser environment, and start executing workloads in the cloud? There was enough stuff there already, thanks to Aaron and others that we could just dive right in. It was excellent. I didn't have to do the hard work of writing interpreters, or JIT compilers, or anything?

Asm.js

Eberhardt: It's interesting you mentioned asm.js, I encountered that when it first started making waves on Hacker News, which must have been about six or seven years ago. I must admit, I just didn't get it. I got that it was cool and flashy, but I just didn't understand what it was for. Asm.js is a subset of JavaScript, which has a few weird attributes. It has effectively type hints that are built into asm.js. It's a very restrictive subset of the language. Also, it removes the need for any garbage collection. It removes the need for any allocation. Everything sits in arrays and things like that. At the time, I just didn't understand why this thing existed. It was only, similar to yourself, when I came across WebAssembly afterwards that all of a sudden asm.js clicked. It was like, it's effectively a proof of concept for a new virtual machine that will genuinely exist within the browser. For me, what got me into WebAssembly was just, I really enjoyed the simplicity of it, in that I've been doing web development for years. The more I learn about web development, the more I realize, I just understand less as time goes on, because everything gets more complicated.

I know, similar to Aaron, I like tinkering. I like looking underneath the covers. Whenever I look underneath the covers of things like React, or webpack, I just take a few steps back and go, I don't get it. Whereas with WebAssembly, I started looking under the covers and realized, I can actually genuinely understand all of this to the point I can write my own WebAssembly virtual machine. For me, what attracted me to WebAssembly the most was just the simplicity of this brand new technology to be able to get in there at the ground level before it's exploded and got too complicated for my little brain to understand.

WebAssembly Language Support

Moving on to the present, common topics that have come up in our questions throughout the sessions have been along the lines of, is it ready yet? What can we do with it at the moment? I think it's probably worth exploring the current state of WebAssembly. A good starting point, to my mind, would have to be language support, because WebAssembly is a language agnostic runtime. It needs languages that support WebAssembly. I'm just interested in people's opinions. What do you think is mature? Where do you think we need to make additional investments? What do you dearly want to see supported within WebAssembly?

Thomas: Understanding the bias where I'm coming from, with my past experience, I would really like this in Go, post-haste, because it is something that everyone is using for the cloud, particularly when integrating with things such as Kubernetes. It's become a lingua franca of the cloud in a sense. I think that's a really big one. I also would really want to see Java and C#, just because those are the big languages that people use in enterprise situations. I always jokingly call them the enterprise languages. That isn't meant to be disparaging. They're very well used, and people have things like a very well tweaked JVM running these things at their various businesses. I would really think that those three languages are my top ones that we would get in there. Because if those languages can do it, then I think every other language will go, Java and C# have it, so maybe we should add it too. Those are very big languages to get there. I think that takes a huge chunk of currently existing code and enables it to be written in WebAssembly. That's where I think those are the top languages. I'd really like to see everything, but if we can get those, I think those are a linchpin, like the very start, the keystone of everything. If we can get that into place, everything will fall in. That's just my opinion, of course.

Eberhardt: What do you think is missing? AssemblyScript is there to plug a gap, what's the gap?

Turner: In terms of AssemblyScript, one thing that it's really been focused on is that JavaScript Developer to WebAssembly Developer bridge. JavaScript developers tend to be a very large bucket of developers out there, they have a lot of existing skills and things that I think also would play nice in the WebAssembly world. Offering them a way to use their skills that they already have and learn WebAssembly, using syntax and things they might already be familiar with, some patterns. I think is important in terms of getting more folks to trial WebAssembly and start integrating it into their existing web applications.

I'd also like to echo Taylor's point, in terms of getting on languages like Go, and Java, and things. I'm really excited at seeing WebAssembly GC land, and I feel like that will start to open a lot of doors for those languages to start outputting WebAssembly. That's what I'm also probably excited for next is WebAssembly GC. Also, module imports, I think, is the name. It's either module imports, module linking, there's some other proposal out there, but the idea that we can start linking WebAssembly modules, even if they are written in different languages, and they can talk to one another, I think it's going to be really cool.

AssemblyScript as a Launch Pad for JavaScript Running on WebAssembly

Eberhardt: Do you always think that AssemblyScript will be the launch pad for JavaScript running on WebAssembly, or something JavaScript like, or do you think at some point in the future JavaScript itself might run on WebAssembly?

Turner: I think it depends. In the current state of things, I would say, yes. That being said, I don't want to pin it as, if you know JavaScript, you can only learn AssemblyScript, because there have been a lot of JavaScript developers that take a look at Rust, and they're like, it works for me. There's also a lot of JavaScript developers that are like, this does not work for me. I think we'll see more languages popping up. Whatever I think has really good JavaScript to WebAssembly support, syntactically, or maybe documentation, however, they might be able to crack the puzzle. I think we might start to see more of that as well, just because it is such a large bucket of developers.

WebAssembly's Language Ecosystem

Eberhardt: From a language ecosystem point of view, have you got a particular favorite language? Are you wanting COBOL, or something like that to come to WebAssembly?

Butcher: It was between that and Fortran. No, I would really like to see really top class Python support in there. A lot of the most promising applications of WebAssembly have to do with a lot of those same kinds of scientific number crunching applications that Python does. With the JavaScript, AssemblyScript thing, we're big fans of AssemblyScript, because you can build very compact WebAssembly binaries. It's really weird to me to talk about a JavaScript-y like high performance language, because I'm so used to those two terms being at opposite ends of the spectrum. That's where I think AssemblyScript is going to shine for us is when we need to do some of those very careful WebAssembly things. I think if JavaScript lands wholesale in the WebAssembly ecosystem, it'll be at the other end of the spectrum, because it's going to need the garbage collection and stuff like that. I think AssemblyScript, what we're going to see is, living up to the assembly part of its name, really being used for some of the high performance stuff.

I loved the fact that when I wrote my first AssemblyScript, it was Hello World in a couple of seconds because I'm familiar with TypeScript. AssemblyScript feels like TypeScript, and you just have to learn a couple additional things that you got to remember to think about there. Then once you got that down, it's a really pleasant experience to write. To then expand that into a bigger point, I think we'll probably see some languages that get hyper-specialized for WebAssembly. They'll get traction, because we need that stuff in order to do some of the computing we want to do. Then we'll see at the opposite end the languages that compile, but you get like Swift, a gigantic runtime along with it to handle all the garbage collection and maintenance. It's a great experience for people who want to go from Swift to WebAssembly. I don't think it'll win size and performance awards in the same way.

Getting into AssemblyScript

I would like to hear the story about how you really got into AssemblyScript and what really got you excited about that idea?

Turner: The way I got into it was when I first started, like it was stable in all browsers. I was coming from a JavaScript background. Then I saw that AssemblyScript was still the AS-next prototype. I was like, "This is probably not going to work, because it's so new." I heard Go had Wasm support, so why don't you go try that out? I was like, "This one also doesn't work because it's so new." Already I had this mindset that I was like, if it's stable on all browsers, the tooling must already be there. People are using in production day one. I didn't know it was so groundwork there. After I tried out Go, and I was like, this is equally not as ready. I just bounced back over to AssemblyScript. I was like, I'm doing the thing. It's working for me. I end up finding all the bugs, and I just started talking with author Daniel. I also won't take too much credit here, because we are a team. I actually don't spend a ton of time writing compiler. There's actually multi-compiler authors we have and they're the ones that are knowing like, let's optimize this module binary down to every byte. I want to give them credit as well. We all just started hanging out on Slack channels and stuff, and just working through, which way should the project head? How should we set up governance, so on and so forth? Here we are. It's how I got involved.

Eberhardt: I know what you mean about the core AssemblyScript team. I've been contributing a little bit recently. Every time I've put in a pull request, they're like, yes, this is great. Then Max comes along and goes, I'll change this and this. I'm like, that's amazing. That's really cool.

Getting WebAssembly onto the Next Level

You told us a little bit about language support. One of the big themes throughout this track has been focusing on WebAssembly outside of the browser, and WASI is quite pivotal or an important foundation to WebAssembly outside of the browser. I'm wondering, again, what do you feel is missing at the moment? What do we really need to get WebAssembly on to the next level? What can we do now? Where do we need to get to?

Butcher: Aaron already actually hinted at the big thing, which is actually core WebAssembly, that's module linking. A way to say, I've got this WebAssembly module that's like libmath, and I want to write my own my.wasm module and pull in libmath.wasm into mine, and have all the function calls available. That I think is going into the core WebAssembly specification. That's one of those keystone things, or once we've got that we can really start piling on the things we absolutely want in the WASI world, like IO arrays, and IO streams will allow us to stream and chunk data in and out of the WebAssembly runtime. With the addition of WITX we'll be able to define what the APIs are. The idea is that as we get going, WebAssembly is great right now in-browser for handling some of the more computationally intensive stuff. In-browser, it's fairly easy to link the JavaScript runtime and the WebAssembly runtime, and be able to do things back and forth.

On the cloud native side, what we really want is to be able to compose fairly sophisticated applications. I wouldn't say ad hoc, but really at startup time where you want to say, here's my module. My module needs a key-value storage. It doesn't care if it's Redis or if it's some cloud service, or something like that, it just needs it, and here's the contract it needs to fulfill. The runtime can link it at runtime and say, here's the key-value storage that fits your requirements. I also need a number crunching library that has access to a GPU or can simulate it, and the runtime can give you that thing.

That's where I think on the cloud native side, that startup time, linking of lots of related features, is what's going to be a watershed moment for us. The first real time where you're going to stop asking the question, what's the difference between running this as WebAssembly and containers? Because all of a sudden, it'll be clear to everybody, "I see. It's basically like running microservices," but whether they're on the same process, the same piece of physical hardware, the same network, the same cloud provider, none of that stuff will matter anymore. It'll just be about whether or not the runtime can wire everything up effectively for it. I think we'll see those kinds of changes really enable huge ecosystem growth and a whole new area of innovation.

The Current State of WASI

Eberhardt: Aaron, a similar question to you about the current state of WASI itself and the ecosystem around that. What are your thoughts and feelings on the current state of WASI? Where does it need to get to?

Turner: I think the current state of WASI, personally, I think it's pretty far along already. I know a lot of the use case for it is mostly just file IO type stuff. Even just that, you think about, you can do a lot of stuff around files. If you add in a few additional host calls for whatever your platform may be, or whatever you're trying to build, then you start to have pretty much 90% of your code base standardized on top of a set of host calls. Give an extra 10%, you can start doing some really cool things with it, like you can see with multiple platforms out there these days, if you look into the WebAssembly cloud space.

Personally, though, I think what's going to be probably really big in terms of getting people to adopt WASI more is socket support. I know that's been in the spec for a while and once socket's in, I think we'll start to see a lot of our server tinkerers to start, ok, this WebAssembly thing is for real now, let me go write my server on top of it. Then we'll start to see some really cool projects, especially in the open source space for WASI.

Thomas: I think it's tied to the socket support is the idea of streams. It's a lot of complexity to go in here. Honestly, I am not as good at the low level details with this. The streams thing is what's going to be used to probably enable things like sockets. Basically, it's a nice pluggable API for you to do some crazy like, can I plug in this random thing into a WebAssembly and be able to do it in a standard way that I think will be really interesting? I think that's the next level that people will really be able to latch onto the whole WASI spec and what it offers, is because there's even more that you can do to extend it. That's been our focus really, and what we hope to see. In our talk, we argued for the trying to keep as much of this as community driven decisions as possible, because we want a good foundation for everyone to go build their random ideas and competing products on. Having that good foundation will really be powerful for us. That's where I think we're at.

Eberhardt: Again, reflecting on the need for stream support, almost all of the interesting non-browser applications of WebAssembly are something to do with networks, whether it is edge, whether it's Krustlet, or IoT style devices, almost everything needs to access a network to do something useful.

Consumer Edge and IoT Devices Explicitly Built on Wasm

I'm curious if anyone has a guess as to when we'll start to see consumer edge or IoT devices shipped that were explicitly built on Wasm.

Turner: I don't know a ton about the IoT space, to be completely honest. I do know where to point you. One of the most interesting things I see with WebAssembly and IoT is Wasm3. I think the author's name is Volodymyr, but they've made a lot of really cool demos of them running WebAssembly Arduinos, and things of that sort. I saw a tweet with a Raspberry Pi Pico page that has a link to one of their projects, of the Chrome Dinosaur game written by Ben Smith, running on Wasm3 on a Raspberry Pi Pico.

Another thing I take a look at is I know Jonathan Beri, who is the host of WebAssembly SF, they recently spun off to do WebAssembly IoT work. Maybe I'd also take a look at their Twitter page. I think it's, @beriberikix is their name. If you look up Jonathan Beri, or WebAssembly SF for San Francisco, you should be headed down the right path to finding that answer. Personally, I wouldn't know the exact date.

Wasm3

Eberhardt: Taylor, Matt, in your presentation where you listed a whole load of WebAssembly runtimes, I think Wasm3 was in the list. I think Wasm3 is an interpreter rather than a JIT compiler. I think there are various reasons why that is a better fit for resource constrained IoT devices.

Butcher: Yes, because it's interpreting the instructions as they go through, so you can allocate fairly small chunks of space to be able to execute the WebAssembly binary. We have been experimenting a lot with Wasm3, and Arduinos, and Pis, and various other pieces of hardware we could get our hands on. Because of that we wanted to see, can we really get this down into small devices? We were just experimenting. My team doesn't build IoT devices. A lot of us want to build IoT devices, so we played around with it. This could work. I would have pointed you to the same people Aaron did. Jonathan Beri seems to be the most high profile one there, and definitely is well connected and can point people in all kinds of different directions.

I think somehow, the SSVM team seems to be interested in some lower level embedded applications of WebAssembly. I don't think it is coincidence that Intel is in the Bytecode Alliance. I think we're all going, how low can we push some of this stuff on the stack to solve problems? The isolation layer that a Wasm virtual machine provides you from the host environment, that's a good security boundary to have. Is this a potential solution for some of the low level architectural attacks we've seen over the last couple of years? It might be. It's worth investigating. The IoT application and the hardware security application of WebAssembly, I think, are going to start coming together. Trusted Computing is another area where you see a lot of WebAssembly interest. The primary thing a Trusted Computing engine is interested in is, can you execute a workload on a compute instance of some sort, and protect that workload from an attack that comes via the host into the workload? A lot of times we're talking about sandboxing the running WebAssembly module from being able to do anything dastardly with the underlying host. This is taking it the other direction and trying to prevent the host from being able to influence the binary that's executing in it.

The fact that all of these people are looking at WebAssembly and saying, I think there's something here. I think the trust model here is good. I think the hardware to software layer abstraction here is good. While we might not see a lot of IoT right now, and we might not see a lot of production workloads on this right away. All that I'm seeing, and I think probably Aaron, the same is true for you, that we're seeing a lot of people who are very interested in figuring out if we can run these kinds of applications on what a couple of years ago we would have called exotic environments and devices.

Eberhardt: You guys have got a lot of excitement for the future of WebAssembly. We're solving software supply chain attacks, but we're also going to solve Spectre and speculative execution attacks, so WebAssembly is going to solve a lot.

Butcher: That's the good thing about being early in a technology, you can just promise everything because nothing's been done yet. Yes, it'll solve everything. Wait until it solves world hunger, I'm telling you, somehow it's going to happen.

Is WASI Open Source?

Eberhardt: WASI is fundamentally a specification, rather than code. Like many specifications, it's being developed in the open.

Ways to Contribute To WASI Spec

Is there a way to contribute to WASI? Yes, there certainly is. Have any of you actually been actively involved in the WASI specification creation?

Turner: I've done half of something before. I think I might have maybe had one contribution to the spec. I tried to do a bigger one. I know how the process is. I have a PR that it's out there that I actually never finished. Why do I bring it up? Yes, it's easy to contribute. It is a little interesting to get used to the WITX files and things. Really, you're just defining an interface for the most part. You use WITX and you say, these are the functions that I think should be the host calls that the WebAssembly takes, and these are the types it should take in, and what it should return. Then you have that reviewed by folks, I think weekly, or every other weekly meetings, where you get to talk to the champions and folks that are involved, and you get to propose things. They'll review it with you. It is a long process, so you have to be ready for the long haul if you want to start getting into spec work. Definitely, there is a path to contribute to WASI. The community is really nice. I started this, like a frame buffer thing, and then COVID happened. I was like, I don't have time for this anymore. Be prepared for the long haul if you want to do this.

Eberhardt: I remember you created, was it Display IO, or Device IO, or something like that, yes, you created that within AssemblyScript, didn't you, for your Gameboy?

Turner: Yes, I made like an IO devices type, like proprietary thing that we had, while working somewhere else. Then we thought it'd be cool if like, let's try to contribute to WASI. Let's make an actual standardized version of it. Then just ran out of time in terms of doing that. One thing about me is I have an open source to-do list on my personal to-do list, and then I just work through it as I can. That won't get pushed more, because other things happen.

Thomas: This is something for people who are worried about getting to the spec, or don't feel comfortable with some of the lower level decisions that are made there like myself. I generally provide feedback in the form of using things on the very edge of this. We use the most recent version of various runtimes and things, and really just push, particularly in Krustlet, just we can push things out and say like, "We're using this." Then people are like, "I didn't think it'd be used like that," or, "It's good to see someone using it in that way." Even just having that data, I think for any project in general, this is good advice, but I think particularly right now in the WebAssembly world with everything being so new, with Krustlet, for example, our project. Just people trying it and saying, "I tried to run this thing, and this didn't work. Why didn't it work?" Or, "I want to be able to do this thing. I know it's not possible now, but could we add this?"

Those discussions and questions add a bunch to the ecosystem and allow us to iron out any of the wrinkles in the way we're implementing stuff. Because we're all humans, and we can get tunnel vision and get a little bit focused on where we're at. If someone who works in a government or in a banking thing, which I don't really interact with that often, comes in and says, have you thought about doing this? That's a perspective that I haven't thought of. I think that's valuable for the entire thing. Even if you're not really comfortable with going deep down into the spec, or the runtime implementation, just using the runtimes, and using the projects is very helpful. I think all of us on here maintain open source projects. That is very valuable to us, as we help improve our projects.

Eberhardt: I think you're right, in that contributing to specification development in terms of actually proposing a new specification or an enhancement, is quite challenging. You're completely right, real end user feedback is valuable in all open source regardless of whether it's specifications or projects.

Butcher: Discord servers for WebAssembly are a great place to get started. I know Aaron, you run the WebAssembly Summit one. Then there's another one as well, I don't actually know who runs it. I tend to hover around in there. I probably don't talk a whole lot in there, but I learn a lot just by scrolling through and reading. Oftentimes, the channels are broken down so you can click on the WASI one and read through what people are doing there. Click on the browser one or the Rust one, and just catch up, ask questions. It's a great place to ask the "beginner questions" because people are very friendly and easygoing in there. I like the whole feel of Discord. It feels like gamer oriented, so it feels more fun. On top of that, the community there I feel like is not just polite, but actually really welcoming and friendly.

Where WebAssembly Will Have the Biggest Impact

Eberhardt: We're talking about the past, present, and future of WebAssembly. It's crystal ball time. Where do you think WebAssembly will have its biggest impact?

From my perspective, I find it quite hard to answer because I get excited about all kinds of different things within WebAssembly. One thing that I don't think has been mentioned much is smart contracts, blockchain. I think smart contracts as a technology themselves as something we've not yet realized the true value of smart contracts, and that model of distributed computing. WebAssembly is such a natural fit for smart contract engines for so many of the reasons that Matt entirely you covered in your talk. It's pretty much an ideal runtime for that type of execution environment. I do think that WebAssembly as a smart contract engine is something that could be really quite big in the future.

Where do you think WebAssembly is going to really go crazy in the future?

Turner: The one that I'm probably most excited about personally, and maybe it's more of a longtail thing. The other reason why I'm so happy about WebAssembly is when I was going through college, and building JavaScript apps and things, I remember going to a lot of hackathons, and be like, it'd be cool if I can build a video editor. Then just being, there's eventually a performance wall that you hit. You just can't build certain types of applications in the browser, and have it run natively in there. That's not fun. You have to learn C to go write this thing. Now that we have WebAssembly, those doors are unlocked. Even for me personally, there's a lot of unlearning I have to do as a web developer of like, what can I do inside my web browser?

I'm really excited to see new applications like music editing applications, video editors, and video games. I'm really excited for the day that maybe I can have grandchildren, and they're like, I'm playing a new whatever in Chrome. It's like, we could never do that growing up, or whatever it may be. Just these really high performance web browser applications that now could be built. That, as a community of developers, have to unlearn and go, we can build that now, inside the browser and distribute it in the world's greatest untrusted code execution environment, which is the web browser, whatever you want to call it.

Butcher: That's the best description of a web browser I've ever heard. The world's greatest untrusted code execution platform is totally right.

Eberhardt: We shouldn't forget where WebAssembly came from. I think you're right. We're just at the very beginning of seeing what WebAssembly can do within the browser. I don't think it will be long before people stopped mentioning that something runs on WebAssembly.

I was being interviewed for a podcast. I was being interviewed about WebAssembly. I noticed that the software that was recording the podcast was using WebAssembly. I never realized that. I thought that was really cool. It will become commonplace.

Where do you think it will have the greatest impact?

Thomas: I think some of the biggest things will be around, basically, what we call constrained IoT and edge devices. To make it more buzzworthy, democratized compute. It doesn't really matter where or how you run it. You can run it pretty much anywhere, and based on the needs. What Matt was referring to earlier is that you have the different places that you might end up running something, the runtime can assemble all these things together. I think that's one of the biggest things we see in the future. Functions as a Service plugins, those kinds of things are the second thing, where it's like, I can write something in any language and have it be run anywhere we want it to, on that system. If I have something that's written in Rust, but people aren't writing in Rust, they can write their plugin in Go, or JavaScript, or whatever, and then it'll just run because it's compiled to WebAssembly.

Eberhardt: I think that's a great answer, it's because the vision of what cloud computing is, is a little bit incorrect. You see diagrams with a line going off into a cloud, and you think it's this big, vast expanse. It's not. It's quite lumpy, really. It's 20 or 30, great big data centers. It's someone else's computer. It's not a democratized distributed runtime. It's far from it.

Butcher: I think, for me, the biggest promise is, to wax philosophical very quickly, we do get these little speed bumpy development cycles, where we try and build something and it works or doesn't work. We had distributed component object models and CORBA, and things like that, decades ago now. It was a good idea. We just couldn't quite make it work in the environment it was in. Then we had microservices more recently, which has been a very promising technology, but then we have to swallow large chunks of time just doing network transactions back and forth. We could list a couple other examples like that. I think I've got this rosy and positivistic view that we're converging on something, and WebAssembly might not be it, but it's starting to feel like it. We're starting to really learn how we might be able to build distributed computing, and solve that problem in such a way that, as Brendan Burns, my boss likes to say, "What we're shooting for is distributed computing being a 100 level class in college. Not the thing you study your very last semester before you get your degree, but the thing that's the entry point."

WebAssembly is starting to feel like a lot of the technologies that we've been fiddling with over decades now to make distributing systems happen. CSP models, and microservices, and common APIs, and dynamic linking are all starting to coalesce or maybe congeal. That's where I'm really excited, because I think, even if we don't manage to get it right this time, we've made a huge amount of progress with WebAssembly. It's really starting to show some promise that we're making traction on distributed computing 101 instead of graduate level classes.

 

See more presentations with transcripts

 

Recorded at:

Mar 18, 2022

BT