WASI 0.3.0 ships: async is now a first-class WebAssembly primitive

What happened

The WebAssembly Working Group cut WASI 0.3.0 on June 12, the first release to fold native asynchronous I/O into the standard itself. The release ships three new core types in the Component Model — `stream`, `future`, and a revised `error-context` — and rewrites every I/O-shaped world (`wasi:io`, `wasi:sockets`, `wasi:http`, `wasi:filesystem`, `wasi:cli`) to use them. The 0.2.x `pollable` machinery, which forced guests to drive a `poll-list` of handles in user code, is gone from the new worlds.

WASI 0.3.0 is the first version where async is a property of the type system, not a convention bolted on top of a synchronous ABI. A function returning `future` is a real component-model future at the ABI level: the host can suspend the guest, run other tasks, and resume it without the guest knowing or caring what executor sits underneath. The same applies to `stream` for byte pipes — it replaces the awkward `input-stream` / `output-stream` resource pair from 0.2 where every read was a synchronous call against a host-managed buffer.

The release also formalizes the `wasi:cli/run@0.3.0` entrypoint, the `wasi:http/handler@0.3.0` world (the spiritual successor to `wasi:http/proxy`), and rewrites the sockets world around `tcp-socket` and `udp-socket` resources that return streams directly. The Hacker News thread (240 points, 180 comments at time of writing) was dominated by runtime maintainers — Bytecode Alliance contributors, Fastly's Jco team, and a few WAMR folks — debating implementation timelines rather than the spec itself.

Why it matters

The story most people will tell about 0.3.0 is "WASI got async," but that undersells what changed. 0.2 already had async — it just made you write it. You called `poll-list` with a vector of pollable handles, the host returned which were ready, and you re-entered your runtime's scheduler. Every language ecosystem ended up with its own shim: `wasi-async` for Rust, the `wasip2` patches for Go's runtime, the `asyncio` event loop hacks for CPython's WASI port. None of them composed across modules, because the async-ness lived in the guest, not the interface.

0.3.0 inverts that. When a host function returns `future`, the runtime owns the suspension point — your code just awaits it, and the executor is whatever the host (Wasmtime, Jco, a browser, an edge platform) provides. This is the difference between every language reinventing epoll wrappers and every language getting `async/await` semantics for free at the FFI boundary. Rust's `wit-bindgen` will lower `future` to a real `Future` impl. The Go binding will lower it to a goroutine that parks on a channel. Python will lower it to an awaitable. The interface is the same; the idiom is local.

The second thing 0.3.0 quietly does is finish the migration off the Preview 1 ABI. Preview 1 (the `wasi_snapshot_preview1` you still see in `wasm32-wasi` toolchains) was a flat list of C-style syscalls — read, write, fd_close, clock_time_get. 0.2 introduced the Component Model and reframed everything as typed interfaces, but kept a Preview 1 compatibility shim because nobody had migrated. 0.3.0 drops the shim from the canonical worlds. If your build pipeline still targets `wasm32-wasi` instead of `wasm32-wasip2`, you are now officially on a legacy ABI that the spec authors have stopped iterating on.

The community reaction is split along a predictable line. Runtime authors are pleased — Alex Crichton's comment on HN ("this is the version where the spec stops fighting the implementation") got 89 upvotes. Application developers are skeptical, because the runtime support matrix is incomplete. Wasmtime has experimental 0.3.0 support behind a feature flag. Jco (Fastly's JS-side runtime) has partial async lowering. WAMR, the runtime that ships in most embedded use cases, has no 0.3.0 support at all. wasmCloud is targeting Q3. The spec ships before the runtimes catch up, which means "WASI 0.3.0 support" will be a meaningful purchasing criterion for the next 12 months, not a baseline assumption.

There's also a quieter political story. WASI has spent two years being criticized for moving slowly while Bun, Deno, and edge runtimes built proprietary alternatives. 0.3.0 is the WG's answer: a substantive release that closes the async gap, formalizes HTTP and sockets, and gives toolchains a clear target. It does not close the gap on threading (still in proposal stage) or GPU access (no proposal), and it does not address the persistent complaint that WIT (the interface definition language) is harder to read than Protobuf. But it's the largest single delta WASI has shipped since the Component Model itself.

What this means for your stack

If you're shipping Wasm components in production today on 0.2: don't migrate yet. The runtime support isn't there, the toolchains are still catching up, and 0.2 will be supported for at least another year. Pin your `wit-bindgen` and your `wasmtime` versions and watch the runtime release notes. The migration story from 0.2 to 0.3 is real but mechanical — most `pollable`-shaped code lowers to `future` with minor binding changes — so there's no architectural decision to make today.

If you're evaluating Wasm for a new project, 0.3.0 changes the calculus on edge functions and serverless. The pitch for Wasm-on-edge has always been "faster cold start than V8, smaller than containers, polyglot." The weakness was that any non-trivial I/O workload — a function that hits a database, calls an upstream API, and writes to a queue — required gymnastics around the synchronous ABI. With native `future` and `stream`, a Rust handler that fan-outs three HTTP calls and aggregates them looks identical to the same code on Tokio, minus the runtime crate. That's the missing piece for Wasm displacing Lambda for I/O-bound work.

If you're on the embedded side — IoT, plugin systems, game modding — 0.3.0 matters less in the short term because WAMR and the minimal runtimes aren't shipping it yet. But the typed-stream story is genuinely useful for the plugin case: a host that exposes `stream` to a guest is a much cleaner extension point than the current callback-and-ring-buffer dance.

Looking ahead

The next 12 months are a race between spec and implementation. Wasmtime will likely ship full 0.3.0 support by end of Q3, which means Fermyon, wasmCloud, and Spin will follow within a quarter. The interesting question is whether the browser-side runtimes (Jco, the Bytecode Alliance's component-model-in-V8 work) keep pace, because that's the path to writing one Wasm component and running it on the edge, in the browser, and on a server with no rewrite. If they do, 0.3.0 will look in hindsight like the release where WASI finally became a portable application runtime rather than a curiosity for Wasm-runtime authors to argue about.