WebAssembly, with Matt Butcher (Fermyon) - S04E08

06/15/23 • 37 min

1 Listener

In this episode, we speak with Matt Butcher, CEO at Fermyon. We discuss the four use cases for WebAssembly, why Wasm’s sandboxed approach is so secure, whether there's any danger retrofitting other use cases onto a language that was originally designed for the web, and how limitations like the lack of full networking support are going to be resolved.

Hosted by David Mytton (Console) and Jean Yang (Akita Software).

Things mentioned:

ABOUT MATT BUTCHER

Matt Butcher is the CEO of Fermyon. He is also a software engineer, tech author, speaker, and ex-professor. Formerly a principal software development engineer for Microsoft, he led a team of engineers that built open-source tools for cloud-native computing. They were responsible for Helm, Draft, OAM, Brigade, Krustlet, CNAB, Porter, Duffle, the VS Code Kubernetes Extension, and many others. Together with a team of 10 people from Deis Labs at Microsoft, he started Fermyon, a lighter, faster, and truly serverless cloud, architected to compile and ship code as Wasm binaries.

Highlights:

[Matt Butcher]: When Luke wrote his first blog post and said, “This is for a web browser,” it was built to not be particularly web-browser specific. It really just defined a machine code format in a way to execute that format. That was what kind of drew us to it as a technology. In the core WebAssembly 1.0 specification, there's nothing in there that binds you to a web browser environment, it’s just a straight-up runtime definition. So it was fairly easy to sort of pluck out a WebAssembly runtime and drop it somewhere else. In fact, there are several different WebAssembly runtimes that are not based on the browser at all. — [0:13:36 - 0:14:13]

[Matt Butcher]: If I were thinking about writing a new database, a new high-performance, multithreaded database, WebAssembly would not be the format I would target for this, right? Because there, you want to be able to do a lot of low-level management. Every little microsecond that you can tease out of IO and process manipulation is valuable. So I don't think we'll see those kinds of highly, highly IO-intensive tasks really land in WebAssembly for years because it's going to take the ecosystem a long time to really tune up and be fine-grained enough to deal with those things without compromising on security. It is possible that maybe never will we really want to write the kind of high-performance databases or high-performance number-crunching computing kinds of systems in WebAssembly. — [0:27:57 - 0:28:44]

Let us know what you think on Twitter:

https://twitter.com/consoledotdev

https://twitter.com/davidmytton

Or by email: [email protected]

About Console

Console is the place developers go to find the best tools. Our weekly newsletter picks out the most interesting tools and new releases. We keep track of everything - dev tools, devops, cloud, and APIs - so you don’t have to.

Hosted by David Mytton (Console) and Jean Yang (Akita Software).

Things mentioned:

ABOUT MATT BUTCHER

Highlights:

Let us know what you think on Twitter:

https://twitter.com/consoledotdev

https://twitter.com/davidmytton

Or by email: [email protected]

About Console

Previous Episode

Why engineering sucks, with Eli Schleifer (Trunk) - S04E07

In this episode, we speak with Eli Schleifer, Co-CEO of Trunk. We discuss why engineering sucks, what developers can learn from how software gets built at Google and Uber, how individual developers can improve their coding experience, and why Git commit messages are useless.

Hosted by David Mytton (Console) and Jean Yang (Akita Software).

Things mentioned:

ABOUT ELI SCHLEIFER

Eli Schleifer is the founder and co-CEO of Trunk, an all-in-one solution for scalably checking, testing, merging, and monitoring code. It helps developers write more secure code and ship faster to redefine software engineering at scale. He was previously a technical lead manager and a systems architect at Uber ATG, where he led the architecture and engineering of its self-driving platform. He also lead a team of engineers and technical leads in the development of multiple products under the YouTube Director umbrella and was a lead senior software development engineer at Microsoft.

Highlights:

[Eli Schleifer]: We should trust our engineers and also understand that code is constantly – it's a living document. It's changing all the time. If something gets in that's imperfect but not terrible, that's also okay. So if you have an engineer put up a pull request, you have feedback, leave that feedback and stamp the pull request. Assuming there's trust, then the engineer is going to follow up, fix up your comments, and then land that. There's no additional cycle. If you don't stamp it, that means you're going to— you’re basically saying to this person, “I'm going to hold up your work until you show me that you can actually follow through on the things I'm asking about.” That's a level of distrust that, I think, is not good in a highly collaborative working environment.

— [0:15:48 - 0:16:28]

[Eli Schleifer]: I think this is the biggest thing between a smaller startup and a giant tech company: At a giant tech company, at the end of the year, the giant tech company comes to the employee and is like, “Tell me what you did this year and why you have this job. Tell me all the good stuff you did for us.” At a smaller company, all management knows what all the people are actually doing for you. There’s a clear visibility into what those engineers are adding and contributing to the actual company's efforts. I think the biggest thing to focus on when it gets to 200 engineers or 2,000 is: what are these people actually working on? Who's making sure that there's a director of engineering for each of these smaller groups of 30, 40 people to make sure they're actually pushing towards something that matters, that matters to the company, that's going to move the needle? And that those engineers can still feel pride in and feel like they have impact?

— [0:27:22 - 0:28:09]

Let us know what you think on Twitter:

https://twitter.com/consoledotdev

https://twitter.com/davidmytton

Or by email: [email protected]

About Console

Next Episode

Creating Julia, with Jeff Bezanson (JuliaHub) - S04E09

In this episode, we speak with Jeff Bezanson, one of the co-creators of the Julia programming language and the CTO of JuliaHub. We start with the history of Julia and why it took a while to take off, the key principles behind the language, how it provides the speed of C with the ease of Python, and what it's been like running such a large open-source project. He sheds light on the original motivation for Julia, the process of creating it, and its involvement in AI.

Hosted by David Mytton (Console) and Jean Yang (Akita Software).

Things mentioned:

ABOUT JEFF BEZANSON

Jeff Bezanson is one of the co-creators of the Julia programming language, along with Stefan Karpinski, Alan Edelman, and Viral B. Shah. He is also a co-founder of JuliaHub, a company that grew out of this project. He has a Ph.D. from MIT where he worked as a research scientist and he has authored a number of academic papers on the Julia language. The intention behind the creation of Julia was to establish a language that was both high-level and fast. His work on it has earned Jeff the J. H. Wilkinson Prize for Numerical Software.

Highlights:

[Jeff Bezanson]: You had to give up performance. That was just a law of the universe that they all learned. Then if you wanted performance, you had to use C or Fortran or something. This was just the way it was. I got introduced to that world of thinking in college and I thought it was really surprising because I knew that high-level languages could be fast. I knew there were good Lisp implementations, you had the ML family languages, there were really good high-level languages that had really, really good compilers and could be fast. And nobody seemed to be using them, which I just thought was amazing. I made it this mission to “Can we get all these people to realize that high-level languages can be fast, and they should be using a high-level language that's fast?” So [Julia] is my attempt to do that.

— [0:02:59 - 0:03:44]

[Jeff Bezanson]: People have been trying to speed up dynamic languages of various kinds for a long time. That's been one of the long-running research threads in computer sciences, starting with a language like Smalltalk, for instance. How do you make it run fast? There's a whole zoo of both dynamic and static techniques. There are some really cool stuff people have invented to take these languages that you can't necessarily statically analyze using standard compiler techniques, and yet, nevertheless, generate fast code from them. It’s a fun game to play is how do we compile these languages that are not cooperative? So that makes it a challenge, which makes it a good research problem. But to me, it's kind of annoying because why do you always have to fight the language design? So instead, I approached it from the opposite direction and said, “All right. What are all the techniques that are known and available for doing this? Then how would you design a language to make those techniques work well?”

— [0:13:18 - 0:14:12]

Let us know what you think on Twitter:

https://twitter.com/consoledotdev

https://twitter.com/davidmytton

Or by email: [email protected]

About Console