1. Network IO can be made async but file IO currently can’t.
2. Many operations that are not GIL-blocking are event loop-blocking, meaning threads have a leg up. In fact, many async programs still end up heavily using thread pools.
3. Conversely, it’s also extremely easy to accidentally block the event loop.¹
4. Async requires a full parallel universe of APIs and libraries and it’s tricky to maintain both.

These are all valid and compelling arguments for why asyncio hasn’t been adopted in leaps and bounds. But if we take a step back, I’d claim there’s a deeper reason: async was a step in the wrong direction from a language design perspective.²

async was initially added to reduce the callback craziness of stuff like Twisted while being possible to retrofit into the language. It was successful with this - blocking is fundamentally easier than callbacks³ - but caused new problems along the way.

After having used a variety of languages and concurrency flavors, I’ve developed the following opinions:

1. The async keyword isn’t worth it.
2. Structured concurrency should be the core coordination mechanism.
3. For Python, gevent’s approach was mostly right all along.

Can we get rid of async?

Every language that introduces an async keyword necessarily runs into the function coloring problem, where a single use of async spreads like a virus and infects the rest of the codebase. Function coloring means that it’s difficult to adopt async incrementally. It also splits the ecosystem, forcing library developers to either pick a side or maintain parallel APIs.⁴

I’d argue that JavaScript is the language with the most ergonomic async design. A big part of its success is that (1) the language already had an event loop and used callbacks heavily and (2) the Promises API made it easy to bridge between callbacks and promises. In other words, they were uniquely set up to provide some mitigations for function coloring.

If we broaden our scope from async to overall approaches to concurrency, Go is the clear winner on ergonomics. There are no async or await keywords; when you want a function to run concurrently, write go myfunc(...) and the runtime will run it in a separate green thread (aka goroutine). As a developer, I don’t need to know the details of how these goroutines are scheduled or how many OS threads we have - the abstraction allows me to ignore these details.

package main

import (
    "fmt"
)

func myfunc(s string) {
    fmt.Println(s)
}

func main() {
    go myfunc("runs in a goroutine!")
    // ... other code
}

Go had two critical insights:

1. If the runtime can ensure that a function yields back to the scheduler whenever it does something blocking, good things happen. Specifically, you don’t need the async keyword at all and hence sidestep the function coloring problem entirely. Second, it becomes impossible to block the event loop.⁵
2. Concurrency should be a call-site choice, not an attribute of the called function.⁶

Of course Go had the flexibility of being a newer language that could bake these ideas into the runtime. Everyone else had to deal with backwards compatibility concerns.

Aside: “but explicit yield points are valuable”

One of the other arguments in favor of async is that the program will only switch to other tasks at specific yield points, and therefore is easier to reason about than threads or green threads. “Unyielding,” written by the founder of Twisted, makes this argument most coherently.

I disagree with that argument: while it’s true that concurrency is hard to get right, I don’t think explicit yield points make it that much easier. In all but the simplest scenarios, you still need shared data structures and locks. Armin Ronacher elaborates on this idea in “Playground Wisdom: Threads Beat Async/Await.”

Making concurrency easier

The above Go code sample actually has a bug - depending on what goes in that “other code”, the print statement may or may not be executed. More broadly, coordination and correctness across goroutines remains cumbersome in Go despite the existence of channels, WaitGroups, and context.

Unlike Go, Python has stuff like exceptions and cancellation semantics, and these make full-featured structured concurrency possible.⁷ The core idea of structured concurrency is pretty simple: require that concurrent tasks can’t outlive their parent scope.

import anyio
import httpx

async def worker(name, url):
    async with httpx.AsyncClient() as client:
        resp = await client.get(url)
        print(f"{name} got {resp.status_code}")

async def main_with_structure():
    async with anyio.create_task_group() as tg:
        tg.start_soon(worker, "worker1", "https://a.com")
        tg.start_soon(worker, "worker2", "https://b.com")
        # When exiting the with block, we automatically block until
        # all subtasks complete.
        # If either worker crashes, the whole group is automatically canceled.
        # You'll never leak/orphan a task.

anyio.run(main_with_structure)

This has other benefits as well. It makes resource cleanup, error handling, cancellation, and control-C handling just work. Stack traces are significantly easier to understand because the call stack is still somewhat sensible. I think that reasoning about structured concurrency feels more familiar to developers without a concurrency background. If you’d like to learn more, I’d highly recommend the Trio creator’s “Notes on structured concurrency, or: Go statement considered harmful.”

In my mind, structured concurrency is clearly the future. In Python, Trio and AnyIO have proven that the idea works. It’s important to call out that it’s applicable for all forms of concurrency - async, green threads, threads, and even multiprocessing.

Making Python nicer

As it turns out, the Python gevent library is built on basically the same insights as Go. It uses green threads for concurrency⁸ and makes it extremely easy to spawn off tasks. Since it’s too late to bake automatic yielding into the Python runtime, gevent relies on monkeypatching to make the standard library cooperative.⁹ The end result is that writing gevent code feels pretty similar to writing Go.

import gevent
from gevent import monkey
monkey.patch_all()

import requests

def worker(name, url):
    resp = requests.get(url)  # automatically yields when blocked
    # If this was async, requests would've blocked the event loop.
    print(f"{name} got {resp.status_code}")

def main():
    g1 = gevent.spawn(worker, "worker1", "https://a.com")
    g2 = gevent.spawn(worker, "worker2", "https://b.com")

    gevent.joinall([g1, g2])  # wait for both to finish

main()

While gevent is already quite solid,¹⁰ there are two things we’d need to build to make it a fully viable replacement for async and the asyncio ecosystem.¹¹

1. A structured concurrency layer built on top of gevent. It would be to gevent as AnyIO is to asyncio. Type checking is also important here, and we can draw inspiration from the asyncer library.
2. A shim layer that brings async programs into the fold. It should be possible to build an asyncio event loop implementation that defers to gevent for all of its actual scheduling and execution.

Here’s what an amazing end state could look like:

g.init()  # unfortunately we'll still need this
import requests

def worker(name, url):
    resp = requests.get(url)  # automatically yields when blocked
    print(f"{name} got {resp.status_code}")

async def async_worker(name, url): ...  # omitted

def main():
    with g.create_task_group() as tg:  # structured concurrency built in
        tg.start_soon(worker)("worker1", "https://a.com")
        tg.start_soon(worker)("worker2", "https://b.com")

        # Seamlessly works with async
        tg.start_soon(async_worker)("worker3", "https://c.com")

    print("All workers finished cleanly")

main()

It also introduces some super interesting possibilities for future work. Most exciting to me is the possibility of leveraging free threading (aka no-GIL Python) by turning the gevent scheduler into a Go-style scheduler that multiplexes green threads (aka greenlets) onto multiple OS threads. While making most Python code totally thread-safe is tricky, there’s only a small jump from code that’s safe when run as a green thread to safe across non-GILed threads.

In case it wasn’t clear: I remain excited about the future of Python. I get the circumstances and reasoning that led to adding async, and am grateful that the flexibility it afforded enabled the prototyping of stuff like Curio and Trio. I hope Python leans more heavily towards green threads moving forward and that future programming languages make concurrency and coordination more of a first-class citizen.

Thanks to John Kim, Kevin Hu, and Shihao Cao for reviewing drafts of this post.

A few years ago, there used to be a thriving ecosystem of CI providers, like Travis CI and CircleCI, with healthy competition between them. Nowadays, every repo I come across uses GitHub Actions instead.

How did GitHub corner CI so quickly? By bundling Actions with existing software and leveraging their community.

Bundling

GitHub is owned by Microsoft, and bundling software is a classic part of the Microsoft playbook. In this case, it’s a lot easier to use one provider for both source control and CI, especially when all GitHub paid plans come bundled with free build minutes.² GitHub Actions is automatically available on all repos, whereas other CI tools must be installed through the marketplace. For a product that, at its core, resells commodity compute at a massive markup,³ the reduction in friction probably has an outsized impact on usage. While they once said “GitHub welcomes all CI tools”, it seems some are more welcome than others.

Reusable CI

There’s a relatively short list of ultra-common building blocks people do in CI, like installing dependencies and running linters and tests. However, GitHub also recognized that there’s a long tail of functions developers want to reuse, but GitHub couldn’t reasonably build out themselves, like generating coverage reports, deploying to various cloud providers, publishing releases, and managing caches for various language/frameworks.

GitHub Actions enabled developers to build and reuse these building blocks, and made it easy to publish them open source for others to use as well. GitHub, which already had a huge community of open source-minded developers, was able to bootstrap a rich ecosystem of custom actions fairly quickly. This ecosystem, in turn, makes GitHub Actions easier to use than any other CI tool, because the mundane parts are already done for you. Doing CI with GitHub Actions is as simple as pulling in dependencies when writing software.

A local optimum

While Travis CI and other providers make you use external scripts for reusability, GitHub Actions went one level higher, promoting these composable actions for reusability. With Travis CI,⁴ complex CI logic would be embedded in your shell scripts, whereas with Actions it’s written in a JavaScript-like language embedded within the YAML configs. From the standpoint of technical purity, I think this is the wrong take. I’d much rather write shell scripts that I can run and test locally, and minimize the difference between local development and CI. Nonetheless, I find myself increasingly building complex workflows filled with community-built actions, since it genuinely is a better quickstart experience than building shell scripts someone else has built before. That’s the power of open source, and yet GitHub Actions’s take on it feels like a local optimum.

There’s different takes on how to escape this local optimum - a better build system that interfaces nicely⁵ with CI (e.g. Dagger, Earthly, Bazel) is the most promising so far.⁶ Unfortunately, these tend to be all-or-nothing tools, so unless we scrap our existing build systems and migrate, we’re stuck writing ugly GitHub Actions pseudo-JS YAML spaghetti with no types or unit tests.⁷ The blog post “GitHub Actions could be so much better” offers an even more poignant critique of the user experience, covering the difficult local development experience, lacking debugging experience, and security footguns.

Open source vendor lock-in

The shift to actions and YAML instead of CI shell scripts serves a second, strategic purpose: increasing vendor lock-in. This is where the technical purity of providers like Travis CI hurt their long-term prospects by decreasing stickiness. While it’s easy to wholesale switch to GitHub Actions and then incrementally adopt actions, it’s very difficult to incrementally switch away when your entire CI process is intertwined with bespoke actions. It’s ironic - the code for these actions is usually community-built and open-source, and yet you get locked into GitHub Actions anyways.

Wrap-up

The GitHub Actions product is a collection of frustrating technical decisions (limited local development, print-oriented debuggability, security footguns, etc) and one compelling one: reusable actions.⁸ This technical decision meshed extremely well with GitHub’s already dominant position and enabled them to leverage their community to build a formidable product moat. Coupled with their ability to bundle a generous free tier, it’s no surprise that GitHub Actions became the dominant CI provider on GitHub in just 18 months after launching.

Notes

WebAssembly is at an inflection point. Over the next few years, I expect to see increased adoption of WebAssembly across the tech sphere, from containerization to plugin systems to serverless computing platforms. The following is a discussion of what WebAssembly is, what makes it a relevant technology, and where it’s being used today. I’ll also describe some potentially high-impact applications and make some predictions about its future.

What is WebAssembly?

WebAssembly (abbreviated Wasm) is an intermediate layer between various programming languages and many different execution environments. You can take code written in over 30 different languages and compile it into a .wasm file, and then can execute that file in the browser, on a server, or even on a car.

The name “WebAssembly” is misleading. While it was initially designed to make code run fast on the web, it now can run in a variety of environments outside of the browser as well. Moreover, WebAssembly is not assembly but rather a slightly higher-level bytecode.

Plenty of ink has been spilled on describing WebAssembly and explaining its history, so I’ll simply refer to some good primers here:

• A cartoon intro to WebAssembly - Mozilla Hacks - the Web developer blog
• WebAssembly. Scary name, exciting applications. | Nicky blogs
• How WebAssembly changes software distribution | Max Desiatov

Where does WebAssembly excel?

WebAssembly excels because of the following five characteristics:

• Portable: The binary format for Wasm bytecode is standardized, meaning that any runtime capable of executing Wasm will be able to run any Wasm code.¹ This is similar to Java’s promise of “write once, run anywhere”. In the browser, 95% of users’ browsers can execute WebAssembly, and the remaining gap can be bridged using a wasm2js compiler. For servers, there are runtimes like Wasmtime and Wasmer. Even resource-constrained IoT devices can join the fun using WAMR.²
• Universal: Many languages can compile into Wasm. This support goes beyond systems languages like C, C++, and Rust to include garbage-collected, high-level languages like Go, Python, and Ruby.³ A full list of languages that compile to Wasm can be found here.
• “Near-Native Performance”: Wasm is often described as having “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript, especially for compute-intensive workloads, and averages between 1.45 and 1.55 times slower than native code, but results do vary by runtime.
• Fast Startup Time: The cold start time of Wasm is important enough that it warrants a category of its own. On the server, it can achieve 10-100x faster cold starts than Docker containers because it does not need to create a new OS process for every container. In the browser, decoding Wasm and translating it to machine code is faster than parsing, interpreting, and optimizing JavaScript, and so Wasm code can begin executing at peak performance more quickly than JavaScript can.⁴
• Secure: WebAssembly was designed with the web in mind and so security was a priority. Code running in a Wasm runtime is memory sandboxed and capability constrained, meaning that it is restricted to doing what it is explicitly allowed to do.⁵ While sandboxed, Wasm code can still be granted access to the underlying system, including system-level interfaces and hardware features.

Where is WebAssembly useful?

Speeding up JavaScript

The initial motivation behind Wasm and its precursor asm.js was to speed up client-side code on the web, and there are many examples of Wasm excelling in this arena:

• The core of the Figma design tool, for example, is written in C++ and then compiled to WebAssembly. They found major performance and usability wins by writing in C++, while compiling to WebAssembly cut load times by 3x and dramatically reduced download sizes.
• The password manager 1Password saw up to 13-39x speedups on form-heavy sites when switching to Wasm. Wasm performance is also more consistent than JavaScript, which is important for latency-sensitive applications.⁶

Programming Language Interoperability

WebAssembly lets us more easily cross the boundaries between programming languages. Libraries and frameworks are usually written in a single language, which makes it difficult to make use of that code from other languages without a full rewrite. With WebAssembly, we can more easily execute code written in other languages. This enables us to reuse code rather than reinventing the wheel.

Right now, this is mainly used to port applications to the web. Here’s some examples:

• Figma makes use of a low-level C++ library called Skia for some graphics algorithms rather than building their own or porting them to JavaScript.⁷
• My favorite chess server, lichess.org, runs the world-class Stockfish chess engine in users’ browsers, saving them the computational burden of running it server-side.
• Google Earth and Adobe Photoshop ported their C++ codebases to the web using Wasm.

Porting applications to the web is the easiest place to start, and we’ll likely see that trend continue. However, Wasm’s interoperability is not limited to the browser. It’s also been used to make code work cross-platform and cross-device:

• The Uno Platform is a UI platform that lets you write a single application and have it run across Windows, macOS, iOS, Android, Linux, and browsers. It seems to be fairly Windows-centric, as applications are written in C# and XAML, and so many of the use cases are based around reducing the effort required to port legacy applications to new platforms.
• Amazon Prime, Disney+, and the BBC all use WebAssembly in their video platforms. For example, Amazon Prime uses it to ship new features to a huge variety of device types while maintaining acceptable performance.

Beyond application portability, WebAssembly can also serve as a cross-language bridge on the server-side. Unfortunately we haven’t seen too much of this yet, since the interfaces used to communicate with the operating system (the Web Assembly System Interface, abbreviated WASI) and work across language boundaries (the Wasm Component Model) are still in development and have not yet reached the requisite maturity level.

Plugin Systems

When most applications reach a certain level of maturity, they need to allow for extensibility by end users. Historically applications have reached for copious config systems or built complex DSLs, but these invariably turn out to be exceedingly painful to manage or force developers to work with unfamiliar languages.

Let’s consider an example: configuring request filtering rules in a system like NGINX. In order to do so, a sysadmin must declaratively implement their desired logic in a custom configuration language that they’re unfamiliar with. They’re beholden to the types of matching and filtering operators that the NGINX designers anticipated, which often severely limits their ability to implement the behavior they want. If anything goes wrong, debugging can be frustrating because of the lack of available tooling.

Some newer applications have opted for a different approach: provide a standard set of interfaces and embed a Wasm runtime, and let end users provide Wasm binaries that implement the needed custom logic. This yields a much more flexible and familiar interface for end users: they can implement arbitrarily complex business logic and can do so in whatever language they choose. This was not possible with other languages because of security concerns, but Wasm makes it feasible because the runtime can sandbox the user-provided code.

A few examples of where this is used today:

• The Envoy proxy, originally developed by Lyft and now used across the industry, allows extensions to be built with Wasm and loaded dynamically at runtime. The Istio service mesh, which is built on top of Envoy, has followed suit.
• Redpanda, a Kafka alternative, lets users write in-stream custom data transformations using Wasm.
• The Open Policy Agent allows for policies to be defined using Wasm.
• The Minecraft server Feather uses WebAssembly to run plugins in a sandbox.

Embedded Sandboxing

The idea of embedding WebAssembly within other applications is useful beyond plugin systems. In fact, it can be used to sandbox entire third-party libraries or to construct layers of security for first-party code.

Firefox is leading the way in this area by protecting itself against bugs in third-party libraries, like the ones they use for spell checking or image decoding. In conjunction with a tool called RLBox, which provides a tainting layer, they can protect against vulnerabilities in those libraries without resorting to heavy-handed process isolation. For Firefox, they don’t even ship Wasm binaries in their final release; the process of compiling to Wasm and then transpiling to another language, coupled with RLBox, provides the security they need.

This approach might prevent some serious vulnerabilities from being exploited. Since attackers usually chain multiple vulnerabilities together, such intermediate security layers will probably be invaluable moving forwards.

Containerization

In an oft-cited tweet, Docker founder Solomon Hykes underscored the importance of WebAssembly:

If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. Webassembly on the server is the future of computing.

There’s good reason to believe that Wasm represents the future of containerization. Compared to Docker, it has 10-100x faster cold start times, has a smaller footprint, and uses a better-constrained capability-based security model. Making Wasm modules, as opposed to containers, the standard unit of compute and deployment would enable better scalability and security.

Such a transition isn’t going to happen overnight, so Wasm-based containerization will likely integrate into existing orchestration systems rather than attempting to replace Docker entirely.

I anticipate this space will be buzzing with activity over the next few years. A few projects are already leading the charge:

• Microsoft Azure’s Deis Labs built Krustlet, which is a way to run Wasm workloads in existing Kubernetes clusters.
• Deis Labs also released Hippo, a Wasm-centric platform-as-a-service. I would guess that Fermyon is trying to commercialize that tech.
• With their wasmCloud project, Cosmonic is building a platform and orchestration tier that combines Wasm containerization with the actor model for distributed systems.
• The Lunatic platform also embraces the actor model and seems to have the best support running multiple light containers on top of a single WebAssembly runtime process.
• Suborbital’s Atmo is another platform and orchestration system, but is more oriented towards serverless workloads.

FaaS/Serverless Platforms

Function-as-a-service platforms need to execute user-provided code quickly and safely. Since serverless platforms are often used to run code for short durations, startup times are a particularly important metric. The ultra-fast cold starts and broad language support make Wasm a good choice for serverless workloads.⁸

The CDN-edge computing platforms provided by Cloudflare Workers and Fastly Compute@Edge already provide the ability to run WebAssembly. Fastly claims 100x faster startup times than other offerings in the market, and attributes this speedup to their WebAssembly-based compiler and runtime. Netlify and Vercel are also building products in this space.

The serverless platforms built by major cloud providers aren’t far behind: AWS Lambda launched WebAssembly serverless functions a few months ago, and I expect that GCP and Azure will follow suit.

Blockchains

Platforms like Ethereum and Solana provide a mechanism for users to write code, dubbed “smart contracts”, which can run on the blockchain. Ethereum built a fully custom system, creating a language called Solidity, a binary format for the compiled bytecode, and the Ethereum Virtual Machine for sandboxed execution. Solana opted to reuse some existing innovations, harnessing the LLVM compiler infrastructure to compile C, C++, or Rust code into a binary bytecode format inspired by the Berkeley Packet Filter, but still built their own runtime called Sealevel.

WebAssembly already provides much of this infrastructure: it lets users write code in the language of their choosing, provides compiler infrastructure to produce Wasm bytecode, and has numerous high-performance runtimes.

But if Ethereum and Solana have already built this infrastructure, what value does WebAssembly provide? The main value-add is actually around ecosystems. For example, Ethereum has its own language for writing smart contracts, which means that it is unable to leverage all the libraries and common functions that have been written in other languages. Solana is a bit better since it can use the Rust ecosystem. Assuming the technical challenges can be overcome, WebAssembly opens up smart contract development to a much wider audience and enables them to use the libraries and tools they’re already comfortable with.

I am definitely not the first to make this realization. The Polkadot network, for example, uses a WebAssembly-based virtual machine as its runtime. The EOS virtual machine is also based on WebAssembly. CosmWasm uses it to build smart contracts that work across multiple blockchains. There was also a proposal called eWASM to replace the Ethereum Virtual Machine with a limited subset of WebAssembly, but it seems that effort has since fizzled out. The Wasmer runtime provides a “singlepass” compiler mode that is explicitly built for blockchains, while WasmEdge claims to have an Ethereum-compatible smart contract execution engine.

Predictions and Opportunities

A New Application Architecture

Just as Docker could not replace virtual machines entirely, Wasm cannot replace Docker entirely. For instance, Docker containers can’t run custom OS kernels while virtual machines can. Similarly, Wasm containers can’t use some specialized CPU instructions, like x86’s 256-bit AVX instructions,⁹ and hence can’t compete with Docker on performance for some applications.

In my opinion, the set of workloads that Docker can support but Wasm can’t is currently larger than the analogous delta between Docker and virtual machines. However, Wasm is still a developing technology and hence will incrementally be able to address more types of workloads. Docker’s rise was closely coupled with the rise of microservice architectures. This took monolithic applications that were well-suited for virtual machines and replaced them with microservices that were well-suited for Docker containers. We’ll probably see a new application architecture that takes advantage of WebAssembly’s unique capabilities.

As per Conway’s law, an application’s architecture reflects the communication structure of the organization that produces it. Every new “reference architecture” throughout the history of computing has reduced the amount of coordination that is required between people. From mainframes to virtual machines to Docker containers, the number of people required to produce a deployable unit has progressively decreased. We’ve achieved this by decomposing systems into smaller and smaller components and by allowing the people building those components to work independently against well-defined interfaces. While microservices have decomposed monolithic applications into several small independent services, WebAssembly makes it easier to decompose microservices into even smaller components.¹⁰

What will this look like? Here’s a few possibilities:

• When you split applications into the core business logic and the glue code needed to work with other systems, it turns out that the business logic is usually pretty small compared to the rest. By separating the interface of the glue code from the implementation of the capability it provides, it becomes possible to build business logic-centric applications and delegate the rest to external capability providers. Coupled with the long sidelined actor model, this is the essence of wasmCloud’s approach.
• Another possibility is that serverless architecture is the next step beyond microservices. Most services can be segmented into stateful and stateless portions, and the stateless portions can run as arbitrarily scalable serverless functions. In this case, WebAssembly serves as a convenient and easily scalable runtime for those serverless functions.
• WebAssembly might change the way we take on third-party dependencies. Modern code relies heavily on third-party libraries,¹¹ and most of these dependencies are not vetted fully or frequently. As software supply chain issues like the recent Log4j vulnerabilities come to light, I expect people will start to take the security of third-party libraries more seriously. Approaches like Firefox’s use of Wasm and RLBox to isolate certain libraries will become more widespread. It might also be feasible to isolate third-party libraries into separate capability-constrained containers within the same Wasm runtime, assuming the performance limitations can be overcome.¹²

Brownfield Deployment

Wasm will eventually need to interoperate with Docker in some way. For the next couple years this is not strictly necessary, since Wasm will primarily be used in greenfield deployments with few requirements for backwards compatibility. But ultimately brownfield deployments need to be easy for Wasm to fully win the containerization race, especially in enterprise settings.

One potential outcome is that Docker will integrate a Wasm runtime. While plausible, I expect Wasm will be sufficiently differentiated to warrant separate tooling entirely. Instead, the unification of Docker and Wasm containers will happen at the orchestration layer.

It’s less clear if Kubernetes will effectively integrate Wasm-based execution or if a new orchestration system will emerge. On one hand, Kubernetes is currently the unrivaled king of orchestration. It has incredible momentum, and the Wasm containerization movement would be wise to ride on its coattails. Folks at Microsoft are investing in that future by building Krustlet, which lets you run Wasm workloads in Kubernetes. On the other hand, Wasm code will have different requirements than Docker containers and hence Kubernetes might not be the right fit. For example, it would be useful to set up shared memory for inter-container communication when using Wasm-based third-party library isolation, which would be difficult to do with Kubernetes. Such Wasm-native orchestrators will eventually build bridges that ease migration from or integration with Docker.

While I’m hopeful for the upcoming wave of Wasm orchestrators, Kubernetes is sufficiently entrenched that it’s probably not going anywhere in the short-term.

Standardized Serverless/Edge Framework

Most serverless providers have their own framework for defining routes and lambda functions. Cloudflare, for instance, defines its own “cf” type and provides a CLI tool called wrangler for setting up code scaffolding. Fastly has its own set of interfaces for interacting with caches and logging, and AWS Lambda has a similar setup. The Fission framework for Kubernetes has its own set of libraries for integration with various languages. Some platforms try to circumvent this problem by letting users provide a Docker container, such that the platform only needs to handle execution. Knative and Fly.io both follow this approach. However, they must then keep a “warm pool” of workers to reduce the impact of cold start times, or pass this problem on to their users.

There’s an opportunity to build a standardized serverless function definition and deployment spec. The popular Serverless Framework does a decent job at abstracting deployment, but still leaks provider-specific details into the function implementations. As soon as those details are abstracted away, multi-cloud deployments become much easier and hence the framework becomes much more powerful. It could eventually be like the Terraform of serverless.¹³

Package Management

Every programming language has an ecosystem around it. Most modern languages have a centralized package registry: Python has PyPI, NodeJS has npm, and Rust has Crates.io. Such registries, and the tooling and workflows that accompany them, are important to developing a high-quality ecosystem and making developer lives much easier.

For Wasm, the WebAssembly Package Manager (WAPM) promised to fill that gap. However, in practice the project seems largely dormant. At the time of writing, only three packages have been updated in the past two months. The issue is that packages are supposed to build on each other, but WAPM only works well for standalone Wasm binaries with no inter-dependencies. The other option for a developer is to publish Wasm modules to npm, but of course this is not ideal for building a Wasm ecosystem beyond JavaScript or AssemblyScript as it does not encourage cross-language interoperability.

The issue isn’t really the fault of WAPM or npm, but rather a rough edge with WebAssembly itself.

attempting to write any non-trivial WebAssembly application that tries to interoperate across runtime or language boundaries requires significant effort today, and exchanging any non-fundamental data types (such as strings or structures) involves pointer arithmetic and low-level memory manipulation.

― Introduction to WebAssembly components | radu’s blog

This is exactly the problem that the WebAssembly Component Model will solve. Wasm components standardizes the WebAssembly Interface format, and provides code generators for both implementing and consuming those interfaces. In other words, it lets us easily cross runtime and language boundaries with Wasm.

There’s a big opportunity to build a high-quality package manager for WebAssembly. It should use Wasm components codegen to generate bindings for using Wasm modules from other languages. If the tooling is sufficiently good, it could make cross-language development a breeze, which would be the real unlock for the server-side WebAssembly ecosystem. The Wasm package registry could even syndicate across other package registries, automatically publishing packages with appropriate generated bindings to PyPI, npm, and Crates.io.

Conclusion

At this point you’re probably thinking: if WebAssembly is so good, why isn’t it more widely used? Let me volunteer some responses:

• WebAssembly’s marketing hasn’t been great. The name is a misnomer, since it is neither restricted to the web nor is it assembly. WebAssembly has primarily been marketed and pushed towards web developers, but its real potential lies beyond the browser. The real unlock will come when C++ and Rust developers, en masse, start to recognize the potential that Wasm holds.
• WebAssembly standardization isn’t there yet. For example, the WebAssembly System Interface has numerous extensions that have not been officially standardized, but various runtimes implement a selection of these extensions. The promise of universal portability has not yet been fully realized.
• Cross-language interactions suck. We need WebAssembly components and good code generators for a critical mass of languages before people actually start to use Wasm across different languages.
• The developer experience leaves much to be desired. I’d love to see improvements in tooling, especially around debugging, and integrations with package managers, build systems, and IDEs.
• I hate to say this, but we probably need a few more severe software supply-chain incidents, of similar scale to Log4Shell, before WebAssembly’s library isolation capabilities are fully appreciated.

WebAssembly has been deployed in a fairly impressive list of places and serves an assortment of use cases, but these represent isolated pockets of activity within the broader tech world. Among my friends, the small fraction who have heard of WebAssembly think it’s really exciting in principle, but are not building with it because it isn’t quite mature yet. However, many of these issues are being actively worked on and will probably reach an acceptable state within the next year or two. As such, it seems we’re on the brink of an explosion in WebAssembly activity, ecosystem, and community.

Discuss on Hacker News or send me your thoughts. Thanks to Nihar Sheth, Mohak Jain, Andrew Sun, and Michelle Fang for their feedback on early drafts of this article.

Notes