Extensible WASM Applications with Go

Original Article ↗ Hacker News Discussion ↗

WASI and Component Model Support

  • Thread clarifies that WASI Preview 2 is built on the WASM component model; Preview 1 is more “classic” WASI.
  • Go’s new ability to export multiple functions (not just main) lets Go modules participate in the component model world, after wrapping with tools like wasm-tools component new.
  • Some runtimes (notably wazero) currently implement only WASI Preview 1 and are hesitant about Preview 2+ due to churn, resource constraints, and portability headaches.
  • There’s concern that rushing ahead with non-final features (WASI p1, then p2, maybe p3) will leave a legacy of half-standard, half-proprietary integration layers.

Go as a WASM Source Language: Size, Performance, Value

  • Go-generated WASM binaries are large; this causes practical issues for browser use and platforms with strict limits (e.g., edge workers).
  • TinyGo produces much smaller modules but is slower to compile and requires discipline about imports and reflection.
  • Some question why Go is appealing for WASM given GC overhead and size; others answer: “because people already write Go,” especially for backend and tooling.
  • It’s noted that Go WASM is slower than non-GC languages, and the WASM GC proposal doesn’t help Go much due to interior pointers and unboxed types.

Server-Side and Plugin Use Cases

  • Significant interest in backend WASM: sandboxed user code, data transformation, routing/decision logic, IoT codecs, database UDFs, and multi-tenant compute.
  • Advantages highlighted: strong isolation, architecture-independent binaries, clear host–guest contracts, plugin systems supporting many languages.

Alternatives and Comparisons

  • Alternatives raised: containers (with extra sandboxing), JVM, .NET, native dynamic libraries, LLVM IR.
  • Critics argue containers are heavy and not a strong security boundary for third-party plugins; proponents counter that modern container security is “good enough” and widely deployed.
  • Some see WASM outside the browser as “a solution looking for a problem”; others argue it uniquely fits safe, language-agnostic plugins.

Tooling: Debugging and Garbage Collection

  • Debugging WASM in Go is described as poor; most rely on printf. Go doesn’t emit DWARF for WASM yet, so richer browser tooling can’t be used.
  • Go uses its own concurrent GC in WASM, as on other architectures; it cannot currently rely on Wasm-GC and cannot share GC-managed objects with the host.

Ecosystem Maturity and Governance

  • Multiple comments emphasize that Go’s WASM/WASI work is largely volunteer-driven, so progress and feature coverage are uneven.
  • There’s skepticism about the health and influence of the broader WASM/WASI/component-model ecosystem, alongside optimism from others who see it as central to future server-side compute.