Software Engineering Daily: WebAssembly 3.0 with Andreas Rossberg

Date: January 20, 2026
Host: Kevin Ball
Guest: Andreas Rossberg (Programming Language Researcher, WebAssembly Architect, ex-Google V8 Team)

Episode Overview

This episode features a deep technical discussion between Kevin Ball and Andreas Rossberg, a co-architect of WebAssembly, about the technology’s history, design philosophies, major milestones (especially the 3.0 release), and its trajectory. They explore how academic theory impacts industrial software design, examine WebAssembly’s expanding role far beyond browsers, and discuss cutting-edge features like garbage collection and multi-language interoperability.

Key Topics and Insights

1. Andreas Rossberg’s Background and WebAssembly Origins

• Academic and Industry Roots: Andreas started as an academic working on programming language theory and implementation before moving to Google where the WebAssembly (Wasm) journey began.

  "I used to be more like a researcher in programming language... At some point I switched over to industry, working for Google, working on the V8 team, and that's one side where the whole webassembly thing started." (01:49)

• Pre-WebAssembly Era:

  • Web apps were limited to JavaScript; 'native client' and asm.js were earlier attempts for fast, secure native code, but with limitations.
  • Collaboration among JavaScript engine developers at Google and Mozilla led to Wasm.

  "Before WebAssembly, there were already like two technologies that tried to bring more like native code to the web... At some point it was mainly people... at Google and at Mozilla, so Luke Wagner and Ben Titzer... Let's do it the right way." (02:40)

2. Design Constraints in the Browser Environment

• Security & Safety: Untrusted code runs in your browser—must be sandboxed, with no undefined behavior.

• Limited Environmental Access: No direct file system or OS services; these constraints shaped early Wasm design.

  "The biggest constraint of course is that it has to be safe and secure... you can't afford like any undefined behavior or any kind of other non safe behavior." (04:34)

3. Major WebAssembly Milestones

WebAssembly 1.0 (2017):

• Target Audience:
  Focused on C/C++ and Rust—languages with no garbage collection.

• Feature Set:

  • Linear byte-array memory model
  • Four basic numeric types
  • Functions, arithmetic, and memory manipulation

  "So the 1.0 release was totally targeted at low level languages like C C and Rust... not much more than that..." (05:50)

• Performance Stories & Limitations:

  • Significant speedups in CPU-intensive tasks
  • Still not ideal for high-level languages needing GC or sophisticated runtime support

  "If you're really just doing low level numeric stuff... then that's where WebAssembly really shines. Right. So you basically get next to native code performance." (07:25)
  "For more high level languages... WebAssembly 1.0 is not a particularly attractive compilation target." (07:25)

WebAssembly 2.0 (~2019-2022):

• Main Additions:

  • SIMD/Vector Instructions: For compute-intensive operations leveraging hardware capabilities
  • Reference Types: More flexible function pointers and ability to pass opaque host values (like JavaScript objects) without exposing representation details

    "Another interesting feature... was the addition of what we call reference types..." (10:12)

• Interop Improvements: Made it easier (though not trivial) to interface with host JavaScript and browser APIs.

WebAssembly 3.0 (2025):

• Headline Features:

  • Garbage Collection (GC):
    • Low-Level GC Types: Programmers can define their own memory layouts (structs/arrays), managed by the WebAssembly engine.
    • Remain as low-level as possible: “All you get is essentially structs and arrays. You don't get any objects... built in like you would have in other VMs..." (13:17)
  • Multiple Memories:
    • Now a single module can define and use multiple linear memories, improving modularity and performance for large, composed applications.

    "Contrary to popular belief, you already were able to have multiple memories before... There was just this weird gap... now we've added that." (17:09)

  • Tail Calls, Relaxed SIMD, Better Multi-Language Support
  • Component Model (in progress): Towards standardizing language-agnostic interfaces and true multi-language runtime interoperability (see below).

• GC Opt-in:
  Existing C/C++/Rust-style memory management continues to work as before; garbage collection features are optional and do not add overhead unless used.

  "You can use both together. You can completely ignore... the instruction set that deals with gc." (15:25)

4. Filling the Gaps, Design Philosophy, and Community Feedback

• Intentional Gaps: MVP-first philosophy—launch with minimum viable product, fill planned gaps later (multiple return values, tables, memories).

• Iterative Process:

  • Feedback from engine and compiler authors, language implementers, and even CPU vendors
  • Features often take years, allowing for broad review and real-world feedback

  "... the committee is open for everybody... you have to convince the rest... that it's worthwhile." (25:43)

• Quote on MVP Approach:

  "We always have this MVP concept, right?... focus on the things that we can solve quickly enough even though it still might take eight years. I don't know." (21:31)

5. Multi-Language Interoperability and the Component Model

• Current Limitations:
  • No automatic type/data conversion between languages; interface design is labor-intensive.
  • No direct or standardized DOM/web API access; all interaction is via imported JavaScript glue code for now.

    "Anything you can do or interaction you have with your environment has to come through imports. And that's like Core to its very tight sandboxing..." (32:37)

• Component Model:
  • In-development layer above Wasm, offering high-level, language-neutral interfaces for true modular/multi-language systems.
  • Analogous to an ABI (application binary interface)... "on steroids."

    "The component model has more high level types and they are particularly designed for multiple languages to be able to map to them and talk through these with each other." (36:33) "You can view [it] as an ABI on steroids if you want..." (41:13)

6. Non-Web Use Cases for WebAssembly

• Edge Computing:
  • Fastly and others use Wasm to provide portable, sandboxed execution at the network edge.
• Embedded Systems:
  • Major industrial device makers (e.g., Siemens) use Wasm for cross-device portability; ahead-of-time (AOT) compilation is key.
• AI & Search: Portable scripting of algorithms for diverse and constrained devices
• Blockchain:
  • Wasm’s portable, deterministic semantics enable secure, verifiable computation across decentralized networks.

  "[For blockchains] what matters... is you do replicated computation and then you rely on consensus between the different replicas..." (42:40)

7. Determinism, Sandboxing, and Security

• Determinism Matters:
  • WebAssembly’s spec is highly deterministic and sandboxes away unspecified machine behaviors—critical for blockchains and replicated systems.

    "WebAssembly is to a large extent fully specified and fully deterministic. And with 3.0, we even have a deterministic profile now." (42:40)

8. Comparison to JVM and Other VMs

• JVM is specialized for Java object model; Wasm is intentionally lower-level, which makes it easier to target a broader class of languages and optimize for features like tagged pointers, closures, and small data allocations.

  "JVM is interesting because that is really a VM that was designed for Java... if you don't happen to be like very much exactly like Java, then it's not going to be very fast." (50:37)

9. The Future: Threads, Continuations, and Beyond

• Major Features Coming:
  • Threads: True concurrency for parallel workloads (near completion)
  • Delimited Continuations: A flexible, type- and security-safe mechanism for implementing green threads, async/await, generators, and advanced control flow

    "The two big features... still missing... one is threads... the other is... stack switching... which turns out we model it as... delimited continuations." (53:20)

• Broader OS Integration: Future hope to see Wasm in desktop OSes and possibly even in hardware

  "Why does, I don't know, macOS or Linux or Windows not support it out of the box... the extreme point of that would be to put it into hardware." (58:37)

10. Formal Specification and Verification

• Wasm is formally specified and machine-verified to eliminate undefined behavior, making it potentially the cleanest, most robust industrial programming language platform.

  "We have machine verified proofs that we don't have undefined behavior... it's a whole new level for an industrial programming language that nobody has done before." (60:11) "The reason that WebAssembly has such a clean and fairly safe design is this because we designed, or one of the reasons, at least I would claim, is that we designed with formalization hand in hand..." (60:11)

Notable Quotes & Moments (with Timestamps)

• On the spirit of WebAssembly GC:

  "I always phrase it as low level as possible, but no lower. And so this is a very low level GC feature..." — Andreas, (13:17)

• On why browser APIs aren’t directly accessible from Wasm:

  "Anything you can do... has to come through imports... Core to its tight sandboxing functionality." — Andreas, (32:37)

• On benchmarks and real performance:

  "Trust no benchmarks at home." — Andreas, (09:30)

• On the open standards process:

  "In theory, everybody can join there and propose a feature, but... you have to convince the rest of the committee that it's worthwhile." — Andreas, (25:43)

• On the big non-web use cases:

  "The web is just one among many at this point... It's really intended to be... universal VM if you want." — Andreas, (42:40)

• On formal specification:

  "...we have everything formally mathematically specified and verified. So we have machine verified proofs that we don't have undefined behavior." — Andreas, (60:11)

• On code verification in the LLM age:

  "The more code we let be generated by dubious sources..." — Andreas, (62:54)

Timeline of Key Segments

| Timestamp | Topic | |-------------|---------------------------------------------------------------| | 01:32–02:40 | Andreas’s background and origins of WebAssembly | | 04:11–05:36 | Browser security and design constraints | | 05:50–09:18 | WebAssembly 1.0 features and performance stories | | 10:12–12:50 | WebAssembly 2.0: SIMD, reference types, interop | | 13:17–16:26 | WebAssembly 3.0: Garbage collection, opt-in features | | 17:09–18:37 | Multiple memories, closing initial design gaps | | 21:31–25:17 | Intentional MVP gaps, extensibility, SIMD hardware issues | | 25:17–27:59 | Standards process, community and vendor feedback | | 29:09–30:49 | Language support expansions and tail calls | | 32:12–36:17 | Wasm vs JavaScript for webapps, DOM access, APIs, glue code | | 36:33–42:11 | The Component Model, cross-language/module interoperability | | 42:40–49:36 | Non-web use cases: edge, embedded, blockchain, determinism | | 49:36–50:37 | Portability/sandboxing drivers for non-web adoptions | | 50:37–52:57 | Comparing Wasm and JVM, tagged pointers, functional languages | | 53:20–58:06 | Upcoming features: threads, delimited continuations | | 58:37–60:02 | Vision: OS/hardware-level WebAssembly adoption | | 60:11–63:41 | Formal methods, verification, the future of safe programming |

Final Thoughts

WebAssembly has matured into a crucial, rigorously specified portable code platform reaching far beyond browsers: from edge computing to embedded devices and blockchain. The 3.0 release brings true garbage collection and further closes the gap for supporting high-level (especially GC) languages. Ongoing work on modules, the component model, and OS integration point toward a future where WebAssembly is as fundamental as the OS or the hardware itself. The commitment to formal specification and security positions Wasm as a uniquely robust target in an era of increasingly automated, polyglot code generation.

End of summary.