Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Wasm-Scape Navigator: Sorting Through the M...

The Wasm-Scape Navigator: Sorting Through the Mosaic of Specs (Wasm I/O 2024)

What are the challenges of following the development of the growing WebAssembly ecosystem as a toolchain and runtime maintainer? How do we address hard issues such as backward compatibility? How and how much should we care?

As an early adopter, the WebAssembly space is like a candy shop: I want a little bit of this, a little bit of that. After all, as you overcome the initial shock, all you need to do is pick a language, choose a runtime and a platform, and then code away.

As a toolchain and runtime maintainer, keeping up with the stream of fast-paced updates of a moving target can at times be overwhelming. What are the challenges of adopting and implementing the growing number of proposed extensions both to the application layer and the core WebAssembly spec? What are the tradeoffs of making one choice over another? How should you prioritize the work?

In this talk, we share our experience with evolving the codebase of wazero, the open-source, zero-dependency WebAssembly runtime for Go developers, and we discuss the road ahead: finding a delicate balance between meeting the demand of a growing user base, keeping the trajectory of the industry in sight, and future-proofing for long-term maintainability.

Edoardo Vacchi

March 21, 2024
Tweet

More Decks by Edoardo Vacchi

Other Decks in Programming

Transcript

  1. @evacchi Wasm Threads Spec The spec defines: - atomic operations

    - shared memory It does not deal with: - creating and managing threads - that’s for a follow-up spec Photo by Vishal Banik on Unsplash
  2. @evacchi Wasm GC Spec The spec defines: - a type

    system for shared data structures - mechanism to access fields of these data structures - independent from linear memory It does not deal with: - GC Photo by Erik Mclean on Unsplash
  3. @evacchi Developing a Compiler/Runtime 1. Find Your Space 2. Pick

    Your Battles 3. Build A Stable Platform 4. Learn From Others
  4. @evacchi WAMR: the WebAssembly Micro Runtime “a lightweight standalone WebAssembly

    (WASM) runtime with small footprint, high performance and highly configurable features for applications cross from embedded, IoT, edge to Trusted Execution Environment (TEE), smart contract, cloud native and so on.”
  5. @evacchi history of wazero • Mid 2020: initial development by

    Takeshi Yoneda. • At the time, all wasm runtimes were native libraries • Late 2021: sponsored by as a top-level project art: The Golang Gopher: Birthday Party by hellkni9ht 62 62
  6. @evacchi Chicory - pure-Java runtime for the JVM - in-development

    - interpreter - work on AoT bytecode planned https://github.com/dylibso/chicory 64 64
  7. @evacchi Summary: Find Your Space - who are your users?

    - what are your use cases? - what are your goals?
  8. @evacchi Strategy - small team - focus on maintenance and

    bug fixing - prioritize features with minimal impact - e.g. promise API stability These choices promote stability, but they are also dictated by the size of the team
  9. @evacchi “every feature starts at -100 points” “Every feature starts

    out in the hole by 100 points, which means that it has to have a significant net positive effect on the overall package for it to make it” from Eric Gunnerson's Compendium https://learn.microsoft.com/en-us/archive/blogs/ericgu/minus-100-points
  10. @evacchi new features bring immediate value for instance, wazero 2.0

    delivers a new multi-pass optimizing compiler feature long requested by our users 1.7
  11. @evacchi “Perfect is the enemy of good” e.g. you might

    deliver only 80% of a feature if that covers 80% of the most relevant use cases example: socket APIs - originally not part of WASI preview 1 - waited for user demand before implementing
  12. “Perfect is the enemy of good” only apparently in contrast:

    it does not mean “move fast and break things” you can deliver a high quality, self-contained 80% of a feature
  13. @evacchi new features • bring significant value • user-driven demand

    for implementation ◦ user transparency / feedback ◦ specs may be vague, users give you details • implement only features and APIs with a clear, immediate use case • document all the choices (RATIONALE.md)
  14. @evacchi new specs - wait for a spec to enter

    phase 4 - wait for a wazero user
  15. @evacchi Summary: Pick Your Battles • pick your own pace

    • pick the workload you can sustain • (move fast if that works for you) • bring users into the loop …yet…
  16. @evacchi how we address stability concerns • conservative vs bleeding

    edge • thorough test base ◦ fuzzing the compiler ◦ our own test suite ◦ web assembly core spec v1 + v2 ◦ language stdlibs: tiny go + go stdlib + zig stdlib ◦ wasi-testsuite ◦ benchmarks 88
  17. @evacchi how we address compatibility concerns • low-coupling • taking

    backwards compatibility seriously • cross-platform + tested ◦ Linux/macOS/Windows + arm64/amd64
  18. @evacchi “Perfect is the enemy of good” as mentioned earlier,

    only apparently in contrast: e.g. you might deliver the 80% of the features users need
  19. @evacchi “Perfect is the enemy of good” - also true

    for specs - we made fun earlier of the wasm threads and GC specs - even though the naming is unfortunate, the reason is also related to reduction of scope
  20. @evacchi Profiles proposal https://github.com/WebAssembly/profiles “To enable the use of WebAssembly

    in as many environments as possible, profiles specify coherent language subsets that fit constraints imposed by common classes of host environments. A host platform can thereby decide to support the language only under a restricted profile, or even the intersection of multiple profiles.”
  21. @evacchi Profiles proposal https://github.com/WebAssembly/profiles “To enable the use of WebAssembly

    in as many environments as possible, profiles specify coherent language subsets that fit constraints imposed by common classes of host environments. A host platform can thereby decide to support the language only under a restricted profile, or even the intersection of multiple profiles.”
  22. @evacchi Tracking new specs - different engines should be able

    to track new specs easily - specs should be simple and easy to embrace - if possible, iterative changes - relatively small – no “all or nothing”
  23. @evacchi Build a ladder - if not possible, work backwards

    - define the feature, then build a ladder - describe intermediate steps to embrace that feature progressively - be transparent with your tree of (spec) dependencies
  24. @evacchi Go “Boring is good. Boring is stable. Boring means

    being able to focus on your work, not on what’s different about Go” Russ Cox, “Backward Compatibility, Go 1.21, and Go 2” https://go.dev/blog/compat
  25. @evacchi Go “There will not be a Go 2 that

    breaks Go 1 programs. Instead, we are going to double down on compatibility, which is far more valuable than any possible break with the past. In fact, we believe that prioritizing compatibility was the most important design decision we made for Go 1.” Russ Cox, “Backward Compatibility, Go 1.21, and Go 2” https://go.dev/blog/compat
  26. @evacchi GraalVM: The Journey from Research to Product (T. Wuerthinger)

    “we really really thought that compiling many languages together would be really exciting; unfortunately this didn't really take off very much. The idea of combining Ruby and JavaScript at the same time it's something that we found potentially interesting but it turned out to be just not practical or people didn't really want to run this in production.
  27. @evacchi GraalVM: The Journey from Research to Product (T. Wuerthinger)

    “On the tooling side we do have tools that work across many languages and we developed quite a bit of them like we have a profiler, we have a debugger, all of these across languages. But it didn't work out so well because, I think, people that write in a specific language, they're not willing to do compromises easily. And a tool that’s sort of cross language still has to be on the common denominator. It might not be the best tool for this language, not the best for this other language, so therefore people don't necessarily like it that much.
  28. @evacchi Conclusions (as a user) 1. Find Your Space Find

    the runtime that works better for your use case 2. Pick Your Battles Pick the runtime that has the right pace for your workload 3. Build A Stable Platform Choose the stability you can afford 4. Learn From Others