Wasm Proposal Hot Takes Part 2 | Ep 23 | WebAssembly Unleashed

Here's a comprehensive summary of the YouTube video transcript, maintaining the original language and technical precision:

Key Concepts

• WebAssembly (Wasm): A binary instruction format for a stack-based virtual machine, designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.
• Open Standards Process: The structured progression of proposals through different phases (0-4) to become official WebAssembly standards.
• Phase 3 (Implementation): Proposals that have been implemented in at least two runtimes and are ready for broader adoption.
• Phase 2 (Specification): Proposals for which spec text has been written and debated, and are ready for implementation.
• Phase 1 (Proposal): Ideas that have been formally proposed to the community group and are being discussed.
• Phase 0 (Idea): Initial concepts or ideas that are being considered.
• ECMAScript Modules (ESM) Integration: A proposal to allow WebAssembly modules to be imported directly into JavaScript code, treating them as first-class citizens in the module system.
• Wide Arithmetic: A proposal to add instructions for handling arithmetic operations that might overflow, providing access to the overflow value or indicating whether an overflow occurred.
• Relaxed Dead Code Validation: A proposal to relax the validation rules for dead code in WebAssembly, potentially simplifying compiler generation.
• Numeric Values in Data Segments: A proposal to allow numeric values to be directly embedded in WebAssembly data segments, rather than requiring them to be escaped.
• Extended Name Section: A proposal to extend the name section in WebAssembly to allow naming of more entities, such as non-exported globals and memories.
• Custom Page Sizes: A proposal to allow WebAssembly modules to specify custom memory page sizes, deviating from the default 64KB.
• Stack Switching: A fundamental proposal to enable efficient stack manipulation, crucial for features like coroutines and setjmp/longjmp.
• Rounding Variants: A proposal to address inconsistencies and limitations in floating-point rounding behavior in WebAssembly.
• Compilation Hints: A proposal to provide hints to WebAssembly engines to optimize compilation and execution.
• Custom Descriptors and JS Interop (for WasmGC): A proposal to improve JavaScript interoperability for WebAssembly with Garbage Collection (GC), specifically regarding tracking JavaScript object types associated with GC structs.
• Component Model: A significant proposal aiming to enable modularity and interoperability between different WebAssembly components and languages.
• WebAssembly C and C++ API: A proposal for a standardized API to interact with WebAssembly runtimes from C and C++ code.
• WASI Observability: Efforts to standardize telemetry and observability for WebAssembly System Interface (WASI) applications.

State of WebAssembly Proposals: Part 2

This episode continues the discussion from the previous "Thunderdome" episode, reviewing the progress and state of various WebAssembly proposals as they navigate the open standards process. The hosts and guests discuss proposals in Phase 3, Phase 2, and Phase 1, highlighting key features, challenges, and their opinions on the direction of WebAssembly development.

Phase 3 Proposals (Implementation)

1. ESM Integration (ECMAScript Modules)

• Main Topic: Enabling direct import of WebAssembly modules into JavaScript.
• Key Points:
  • This is a long-held dream for WebAssembly, allowing Wasm modules to be treated like JavaScript modules.
  • It bypasses the WebAssembly.instantiate call, elevating Wasm to the same level as JavaScript in the module system.
  • It does not provide special types like the component model; it primarily deals with standard Wasm types (i32, f64) and reflects WasmGC types with other proposals.
• Champions: Two individuals from Agalia (working on web engines) and Guy Bedford (formerly of Wasmtime/JCO, now at Cloudflare).
• Status: Requires implementation in two browsers or runtimes to advance to Phase 4.

2. Wide Arithmetic

• Main Topic: Adding support for arithmetic operations that can detect or handle overflows.
• Key Points:
  • Currently, Wasm has no mechanism to detect or access overflow values from operations like multiplication.
  • This is crucial for libraries dealing with large numbers (big number libraries), cryptography, scientific computing, and pseudo-random number generators (used in hashmaps).
  • The lack of this feature leads to inefficient code generation by compilers like LLVM, which then translates to inefficient machine code.
  • The current arithmetic in Wasm is significantly slower (around 7x) than native hardware for these operations.
• Champions: Alexey Kladov and Jamie Sharp.
• Status: In the implementation phase, requiring adoption by various Wasm engines to move forward.

Phase 2 Proposals (Specification)

Phase 2 signifies that spec text has been written and debated, making the proposal ready for implementation discussions.

1. Relaxed Dead Code Validation

• Main Topic: Simplifying WebAssembly validation for code that is unreachable or has no effect.
• Key Points:
  • The necessity of this proposal is questioned by some, as compilers often generate code that needs to validate even in unreachable branches.
  • The unreachable instruction is often used as a workaround.
  • Notable Statement: "A dead proposal about dead code."
• Champions: Conrad Watt and Ross Tate.
• Status: Dormant, with no commits to the repository in five years, raising questions about its future.

2. Numeric Values in Data Segments

• Main Topic: Allowing direct embedding of numeric values in Wasm data segments.
• Key Points:
  • Currently, data segments primarily support strings or raw bytes, requiring escaping for numeric values.
  • This proposal simplifies writing Wasm by hand and improves clarity, especially concerning endianness, which can be a common pitfall.
  • It is not expected to change encoded WebAssembly but makes manual authoring easier.
• Status: No major objections, but its advancement depends on community engagement.

3. Extended Name Section

• Main Topic: Expanding the WebAssembly name section to include more entities.
• Key Points:
  • The MVP name section had limitations, not allowing names for non-exported globals or memories.
  • This proposal aims to provide local names for more entities, which are non-semantic but useful for debugging and tooling.
• Status: Has not seen commits in a couple of years, suggesting it's a "nice-to-have" that hasn't motivated significant implementation effort.

4. Custom Page Sizes

• Main Topic: Allowing WebAssembly modules to define custom memory page sizes instead of the default 64KB.
• Key Points:
  • The default 64KB page size can be significant for memory-constrained environments like IoT and embedded systems, especially when multiple Wasm modules are composed.
  • The 64KB was chosen historically as a multiple of common page sizes, but modern architectures often use 4KB.
  • The proposal allows for two options: 64KB and 1 byte (though the 1-byte option is considered peculiar).
  • This is particularly relevant with the component model, where stitching multiple core Wasm modules together can lead to substantial memory overhead.
  • The page size is encoded into the Wasm module itself.
• Champion: Nick Fitzgerald.
• Status: Debated and landed on specific options; implementation is key.

5. Stack Switching

• Main Topic: A fundamental proposal to enable efficient stack manipulation.
• Key Points:
  • Considered one of the most important missing features, present in most real processors.
  • Essential for porting programs that use setjmp/longjmp and for efficient implementation of coroutines in languages like Go.
  • There were significant debates and two distinct camps on how to implement it.
  • It's a challenging proposal to land in engines due to its fundamental nature.
• Status: Spec text exists, and prototypes have been made, but it's a major engineering undertaking for engines like V8 and Wasmtime. The spec text itself is still being refined through implementation attempts.

6. Rounding Variants

• Main Topic: Addressing deterministic floating-point rounding behavior in WebAssembly.
• Key Points:
  • Wasm's current deterministic rounding was chosen for simplicity across architectures, but it excludes some useful rounding modes.
  • This proposal aims to tackle the complexity of supporting these additional modes.
• Status: Currently a one-person proposal, lacking broad community willingness to advance it.

7. Compilation Hints

• Main Topic: Providing hints to Wasm engines for optimization.
• Key Points:
  • Useful for improving performance in specific engines that support these hints.
  • Key Argument/Perspective: Mixed feelings due to potential impact on portability. A Wasm module might perform exceptionally well on one engine but poorly on another, undermining the goal of universal portability.
  • However, it could make Wasm more palatable for high-performance computing, high-frequency trading, and large scientific applications.
• Status: Discussed with mixed feelings regarding portability.

8. Custom Descriptors and JS Interop (for WasmGC)

• Main Topic: Improving JavaScript interoperability for WebAssembly with Garbage Collection (GC).
• Key Points:
  • Addresses aspects of WasmGC and its JS interop that were deemed non-essential for the MVP and were deferred.
  • The core functionality is to determine the type of JavaScript object associated with a WasmGC struct.
  • Gladly separated from the main GC proposal to allow for focused development.
• Status: Seen as a good way to divide work, with the expectation of shipping later.

Phase 2: A Pragmatic Approach

A recurring theme in Phase 2 proposals is that many are pragmatic decisions made to ship core functionality first, with thornier or less critical issues being addressed later. This can be seen as a "parking lot" or "dumping ground" for ideas that are valuable but not immediately essential for initial adoption.

Phase 1 Proposals (Proposal)

Phase 1 represents ideas that have been formally proposed and are being discussed by the community group.

1. Component Model

• Main Topic: A foundational proposal for modularity and interoperability in WebAssembly.
• Key Points:
  • Hilariously still in Phase 1 despite being discussed for years and having significant implementation work done.
  • The work on the spec and implementations (e.g., in Wasmtime preview releases) often exceeds that of some Phase 3 proposals.
  • The component model exists outside the Wasm engine itself, similar to JS interop, meaning engines don't necessarily need to be aware of it natively. This allows for flexibility and experimentation.
  • Current Focus: Async operations and futures are being implemented.
  • The spec and implementation feed into each other, with ongoing revisions based on practical implementation challenges.
• Status: Mature in terms of development and implementation, but formally needs to move through the phases once the spec stabilizes.

2. WebAssembly C and C++ API

• Main Topic: A standardized API for interacting with Wasm runtimes from C/C++.
• Key Arguments/Perspectives:
  • Argument Against: The original value proposition (swapping engines easily) is diminished as Wasm engines have become large and complex. The API covers a small subset of functionality and doesn't leverage newer proposals. It's seen as a maintenance burden for runtimes.
  • Argument For (Historical): Was important in the early days when engines were simpler and fragmented.
  • Alternative Vision: A wasi.wit interface for components would be more exciting and valuable.
• Status: Considered "dead" by one participant, an experiment that failed.

Proposals Not Yet in Phase 1

1. Telemetry Efforts (WASI Observability)

• Main Topic: Standardizing telemetry and observability for WASI applications.
• Key Points:
  • The wasi-observe project is working on this offline.
  • A proposal for adoption exists in Phase 0 but is not yet in Phase 1.
  • Challenge: Lack of consensus on how to observe things in WebAssembly, with different organizations having varying needs and approaches.
  • The effort is trying to narrow the scope, similar to how OpenTelemetry narrowed down observability.
• Status: Still in Phase 0 due to a lack of consensus.

Synthesis/Conclusion

The discussion highlights the dynamic and iterative nature of open standards development for WebAssembly. While many exciting proposals are progressing through the phases, particularly in Phase 3 and Phase 2, the journey is often complex and requires significant engineering effort and community consensus. Key themes include:

• Pragmatism: Core functionality is prioritized, with more complex or niche features deferred.
• Maturity vs. Formalization: Proposals like the Component Model demonstrate significant development and implementation progress, even while formally residing in earlier phases.
• Engineering Challenges: Fundamental features like Stack Switching present substantial technical hurdles for engine implementers.
• Community Engagement: The advancement of many proposals hinges on broader adoption and willingness from the community and engine developers.
• The "Thunderdome" Analogy: The process involves robust debate and differing perspectives, essential for shaping a robust and versatile technology.

The episode concludes with a call to action for the community to engage with these proposals and subscribe for future updates, emphasizing the ongoing effort to "unleash the power and promise of WebAssembly."