5 ms·

WebAssembly has been working just fine since 2017. This article is just hype for WASI 0.2 and the Component Model, which at closer look seems to suffer from se

WebAssembly has been working just fine since 2017. This article is just hype for WASI 0.2 and the Component Model, which at closer look seems to suffer from second-system effect at best, or Rust people ruining a perfectly fine standard (WASI 0.1) at worst.

dxhdr 2y ago
What problems is WASI 0.2 and the Component Model solving? I've read the project goals but I still don't quite understand. I mean, I guess having some defined interface between languages might be useful for some specific usecases, I just don't see what that has to do with WASM and I also don't understand how this complexity would be a net benefit to the broader ecosystem.
- leucippe 2y ago
  For background, WASI 0.1 is one interface: a smaller POSIX. Translating POSIX's low-level ABI concepts into WASM is enough for this. WASI came out of WASM's goal of portability, and 0.1 makes WASM portable across POSIX systems. WASM and WASI aim to support other embeddings. WASI 0.2 introduces an interface for HTTP servers and clients, aimed at cloud/edge. Currently Docker images (on an OS) get used here, but POSIX, even small POSIX, is bloat. WASI 0.2 plans a range of other interfaces for embedding WASM e.g. IOT, so that even without POSIX, you still have portable standards, in your preferred language. HTTP is a high-level idea. HTTP libraries in any language are never about writing binary to TCP sockets, they're about requests and responses. Depending on sockets would miss the point of leaving POSIX behind. A smaller, loosely-coupled API surface gives both sides more freedom. The runtime can work with the system, the language can work with its users, and the tooling can generate minimal glue that links them together. Why define WASI APIs with an abstract interface rather than a rigid binary one? Because it follows the spirit of WASM's existing goals: low-level when needed for performance, and high-level whenever it makes WASM simpler to target, embed or reason about. That's why WASM has low-level assembly instructions yet high-level structured control-flow. It's also why WASI uses types appropriate for the API in question (e.g. files in the POSIX interface, responses in HTTP) yet translates them to binary glue when linking real hosts and guests. Lin Clark's 2019 article[1] raises an issue that comes with low-level interfaces: But if a function takes or returns anything besides numbers, things get complicated. You can either: - Ship one module that has a really hard-to-use API that only speaks in numbers… making life hard for the module’s user. - Add glue code for every single environment you want this module to run in… making life hard for the module’s developer. Clark argues WebAssembly is the right abstraction level to solve this issue in an efficient yet ergonomic way. Frankly, if your WASM module written in Go wants to talk to your host in Java, I don't see why that needs to involve C bindings. The Component Model falls out of WASI as a bonus. WASI needs to interoperate modules with their embeddings. From there WASI may as well (Lin Clark puts it) "interoperate all the things". [1]: https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type...
- pjmlp 2y ago
  Basically since they want to redo P-Code/M-Code/JVM/CLR/BEAM/TIMI/Language Environments/..., now they need to re-invent CORBA, DCOM, XPC, AIDL, gRPC as well. They already reinvented application servers with WASM containers on Kubernetes. Otherwise how one would expect to create startups whose goal is to deliver services on top of WebAssembly, something whose original goal was only being a safer ActiveX, Flash, Silverlight, Applets, PNaCL, asm.js, alongside JavaScript.
- flohofwoe 2y ago
  Exactly. AFAIK the idea is the same as 1990's COM or CORBA, but for WASM (e.g. being able to call between WASM "DLLs" written in different languages but without having to define a C API for each DLL), so pretty much irrelevant for statically linked WASM apps or anything that uses C APIs anyway to talk to each other.
  - jeffparsons 2y ago
    > pretty much irrelevant for statically linked WASM apps One benefit off the top of my head is the extra isolation between component instances within this statically linked app: you can be shielded from many of the ways libwhatever might ruin everything because its linear memory can be totally isolated from the root component (and vice versa) with surprisingly little overhead. The Wasm Component model takes security seriously, much in the way that Core Wasm does. Even without everything else it has to offer, this is something our craft is desperately in need of.
    - nilslice 2y ago
      and CM copies everything everywhere between components - so this fictional need to build your program out of wasm components made of several languages which in turn also may link many components will just be a nightmare for performance and memory. WIT has to have a “borrow” concept to alleviate the pain.
      - leucippe 2y ago
        There's in-progress design work in SIG Embedded to eliminate unnecessary copies, because that will help using interfaces on embedded devices.
    - deleted 2y ago
      [deleted]
    - pjmlp 2y ago
      If Core Wasm took security seriously, the memory access opcodes for arrays would be bound checked like on MSIL and TIMI, instead of "as long as it is inside of a linear memory segment we're good" approach.
pjmlp 2y ago
We don't need Component Model, rather good tooling that makes as easy to spew WebAssembly as using AssemblyScript, not having to install alternative compiler toolchains. Additionally the whole WebAssembly on the server is JVM/CLR/BEAM envy, fuelled with SV money for the next big thing, better served with plain old containers.
jauntywundrkind 2y ago
WASI preview1 modules aren't very modular. You can't compose them. All you can do is one shot compile & bundle the world into one massive module. You can't use that module to power another module, it basically has to be standalone. Luke Wagner has a talk going through WASI 0.2 that's pretty excellent. The title is What is a component (and why)?, and we go step by step through the properties component-model enables: a Standard Portable Lightweight Finely-Sandboxed Cross-Language Compositional Module. You get basically none of these without component-model. https://youtu.be/tAACYA1Mwv4 https://youtu.be/tAACYA1Mwv4 The properties are amazing. Not only do we get Cross-Language, not only do we get composable, but ideally we get very very lightweight sandboxed processes that can safely re-use modules already loaded by the runtime. This could be such an incredible way to sandbox actively, with a base of supportinginrsriss dwarfing anything computer science has done before. The wasm view here has been so shortsighted & brutal. Once again, the hype cycle has gotten big enough that a lot of people are very angry & actively trying to tear down & discredit. Like systemd, like K8s. With not even a passing attempt to show balanced views in the process, no nods to the possible or good, just remorseless total war. This is the famous typical dripping sense of disdain, arising again in angry stirrings, here now to rage against component-model. Holy shit yes is it ambitious and hard. Yes you should be afraid of failure, of this crew not pulling it off & not making it work. But my heavens what a bunch of far-too-typical backhanded mean-girl horseshit is being heaped up to spiritually crush & deaden the effort, convincing everyone we should never try hard or attemot big efforts. I see a future where we can spawn safe secure processes instead of promises, where we can run processes at such scale. Where we can mix languages. There's something so intensely interesting & compelling, upscaling & paving the road for something like V8 isolated that have had such success enabling scalable online platforms, and taking it from exotic dark material for the hyperscalers & turning it to something standard & accessible, fast & secure, spanning the whole technical ecosystem. It's worth the risk ya'll. Maybe we'll hit every branch of the CORBA tree on the way down & fail, but I for one tend to think we're such an improved world since those days: the web technical architecture groups along with open source footing have been an incredible combination for hashing through hard problems & building good protocols & standards piece by piece that let us keep composing better solutions, that let us build upwards successfully. And I'm so excited for this future, for what could be here. Please educate yourself & come correct if this is an interesting topic that you want to engage in; there's so many resources out there. Never have we had a time where it's easier to dig in, from wonderful talks to in depth meeting notes. Please be more serious than oMGggg cORbA gRoSS it'll never work. Most of all, I dare you imagine it does work. And as a smart open minded technical sort, you should leave some space for that as a possibility in your cynicism, should have the possibility of success in your risk profile.

dxhdr 2y ago

What problems is WASI 0.2 and the Component Model solving? I've read the project goals but I still don't quite understand. I mean, I guess having some defined interface between languages might be useful for some specific usecases, I just don't see what that has to do with WASM and I also don't understand how this complexity would be a net benefit to the broader ecosystem.

leucippe 2y ago
For background, WASI 0.1 is one interface: a smaller POSIX. Translating POSIX's low-level ABI concepts into WASM is enough for this. WASI came out of WASM's goal of portability, and 0.1 makes WASM portable across POSIX systems. WASM and WASI aim to support other embeddings. WASI 0.2 introduces an interface for HTTP servers and clients, aimed at cloud/edge. Currently Docker images (on an OS) get used here, but POSIX, even small POSIX, is bloat. WASI 0.2 plans a range of other interfaces for embedding WASM e.g. IOT, so that even without POSIX, you still have portable standards, in your preferred language. HTTP is a high-level idea. HTTP libraries in any language are never about writing binary to TCP sockets, they're about requests and responses. Depending on sockets would miss the point of leaving POSIX behind. A smaller, loosely-coupled API surface gives both sides more freedom. The runtime can work with the system, the language can work with its users, and the tooling can generate minimal glue that links them together. Why define WASI APIs with an abstract interface rather than a rigid binary one? Because it follows the spirit of WASM's existing goals: low-level when needed for performance, and high-level whenever it makes WASM simpler to target, embed or reason about. That's why WASM has low-level assembly instructions yet high-level structured control-flow. It's also why WASI uses types appropriate for the API in question (e.g. files in the POSIX interface, responses in HTTP) yet translates them to binary glue when linking real hosts and guests. Lin Clark's 2019 article[1] raises an issue that comes with low-level interfaces: But if a function takes or returns anything besides numbers, things get complicated. You can either: - Ship one module that has a really hard-to-use API that only speaks in numbers… making life hard for the module’s user. - Add glue code for every single environment you want this module to run in… making life hard for the module’s developer. Clark argues WebAssembly is the right abstraction level to solve this issue in an efficient yet ergonomic way. Frankly, if your WASM module written in Go wants to talk to your host in Java, I don't see why that needs to involve C bindings. The Component Model falls out of WASI as a bonus. WASI needs to interoperate modules with their embeddings. From there WASI may as well (Lin Clark puts it) "interoperate all the things". [1]: https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type...
pjmlp 2y ago
Basically since they want to redo P-Code/M-Code/JVM/CLR/BEAM/TIMI/Language Environments/..., now they need to re-invent CORBA, DCOM, XPC, AIDL, gRPC as well. They already reinvented application servers with WASM containers on Kubernetes. Otherwise how one would expect to create startups whose goal is to deliver services on top of WebAssembly, something whose original goal was only being a safer ActiveX, Flash, Silverlight, Applets, PNaCL, asm.js, alongside JavaScript.
flohofwoe 2y ago
Exactly. AFAIK the idea is the same as 1990's COM or CORBA, but for WASM (e.g. being able to call between WASM "DLLs" written in different languages but without having to define a C API for each DLL), so pretty much irrelevant for statically linked WASM apps or anything that uses C APIs anyway to talk to each other.
- jeffparsons 2y ago
  > pretty much irrelevant for statically linked WASM apps One benefit off the top of my head is the extra isolation between component instances within this statically linked app: you can be shielded from many of the ways libwhatever might ruin everything because its linear memory can be totally isolated from the root component (and vice versa) with surprisingly little overhead. The Wasm Component model takes security seriously, much in the way that Core Wasm does. Even without everything else it has to offer, this is something our craft is desperately in need of.
  - nilslice 2y ago
    and CM copies everything everywhere between components - so this fictional need to build your program out of wasm components made of several languages which in turn also may link many components will just be a nightmare for performance and memory. WIT has to have a “borrow” concept to alleviate the pain.
    - leucippe 2y ago
      There's in-progress design work in SIG Embedded to eliminate unnecessary copies, because that will help using interfaces on embedded devices.
  - deleted 2y ago
    [deleted]
  - pjmlp 2y ago
    If Core Wasm took security seriously, the memory access opcodes for arrays would be bound checked like on MSIL and TIMI, instead of "as long as it is inside of a linear memory segment we're good" approach.

pjmlp 2y ago

We don't need Component Model, rather good tooling that makes as easy to spew WebAssembly as using AssemblyScript, not having to install alternative compiler toolchains. Additionally the whole WebAssembly on the server is JVM/CLR/BEAM envy, fuelled with SV money for the next big thing, better served with plain old containers.

jauntywundrkind 2y ago

WASI preview1 modules aren't very modular. You can't compose them. All you can do is one shot compile & bundle the world into one massive module. You can't use that module to power another module, it basically has to be standalone. Luke Wagner has a talk going through WASI 0.2 that's pretty excellent. The title is What is a component (and why)?, and we go step by step through the properties component-model enables: a Standard Portable Lightweight Finely-Sandboxed Cross-Language Compositional Module. You get basically none of these without component-model. https://youtu.be/tAACYA1Mwv4 https://youtu.be/tAACYA1Mwv4 The properties are amazing. Not only do we get Cross-Language, not only do we get composable, but ideally we get very very lightweight sandboxed processes that can safely re-use modules already loaded by the runtime. This could be such an incredible way to sandbox actively, with a base of supportinginrsriss dwarfing anything computer science has done before. The wasm view here has been so shortsighted & brutal. Once again, the hype cycle has gotten big enough that a lot of people are very angry & actively trying to tear down & discredit. Like systemd, like K8s. With not even a passing attempt to show balanced views in the process, no nods to the possible or good, just remorseless total war. This is the famous typical dripping sense of disdain, arising again in angry stirrings, here now to rage against component-model. Holy shit yes is it ambitious and hard. Yes you should be afraid of failure, of this crew not pulling it off & not making it work. But my heavens what a bunch of far-too-typical backhanded mean-girl horseshit is being heaped up to spiritually crush & deaden the effort, convincing everyone we should never try hard or attemot big efforts. I see a future where we can spawn safe secure processes instead of promises, where we can run processes at such scale. Where we can mix languages. There's something so intensely interesting & compelling, upscaling & paving the road for something like V8 isolated that have had such success enabling scalable online platforms, and taking it from exotic dark material for the hyperscalers & turning it to something standard & accessible, fast & secure, spanning the whole technical ecosystem. It's worth the risk ya'll. Maybe we'll hit every branch of the CORBA tree on the way down & fail, but I for one tend to think we're such an improved world since those days: the web technical architecture groups along with open source footing have been an incredible combination for hashing through hard problems & building good protocols & standards piece by piece that let us keep composing better solutions, that let us build upwards successfully. And I'm so excited for this future, for what could be here. Please educate yourself & come correct if this is an interesting topic that you want to engage in; there's so many resources out there. Never have we had a time where it's easier to dig in, from wonderful talks to in depth meeting notes. Please be more serious than oMGggg cORbA gRoSS it'll never work. Most of all, I dare you imagine it does work. And as a smart open minded technical sort, you should leave some space for that as a possibility in your cynicism, should have the possibility of success in your risk profile.