18 ms·

> The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually rea

> The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime. At the application level, you're generally going to write to the standards + your embedding. Companies that write embeddings are encouraced/incentivized to write good abstractions that work with standards to reduce user friction. For example, for making HTTP requests and responding to HTTP requests, there is WASI HTTP: https://github.com/WebAssembly/wasi-http https://github.com/WebAssembly/wasi-http It's written in a way that is robust enough to handle most use cases without much loss of efficiency. There are a few inefficiencies in the WIT contracts (that will go away soon, as async lands in p3), but it represents a near-ideal representation of a HTTP request and is easy for many vendors to build on/against. As far as rewriting the world, this happens to luckily not be quite true, thanks to projects like wasi-libc: https://github.com/webassembly/wasi-libc https://github.com/webassembly/wasi-libc Networking is actually much more solved in WASI now than it was roughly a year ago -- threads is taking a little longer to cook (for good reasons), but async (without function coloring) is coming this year (likely in the next 3-4 months). The sandboxing abilities of WASM are near unmatched, along with it's startup time and execution speed compared to native.

quesomaster9000 2y ago
I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell. There are a few niches where standardization of interfaces and discoverability will be extremely valuable in terms of interoperability and reducing the development effort to bring-up products that deeply integrate with many things, where currently each team has to re-invent the wheel again for every end-user product they integrate with, with the more ideal alternative being that each product provides their own implementations of the standard interfaces that are plugged into interfaces. But, the reason I'm still on the fence is that I think there's more value in the UNIX style 'discrete commands' model, whether it's WASM or RISC-V I don't think anybody cares, but it's much more about self-describing interfaces with discoverability that can be glued together using whatever tools you have at your disposal.
- hardwaresofton 2y ago
  > I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell. I think we can at least say WebAssembly + WASI is distinct from DLL hell because at the very least your DLLs will run everywhere, and be intrinsically tied to a version and strict interface. These are things we've just never had before, which is what makes it "different this time". Having cross-language runnable/introspectable binaries/object files with implicit descriptions of their interfaces that are this approachable is new. You can't ensure semantics are the same but it's a better place than we've been before. > But, the reason I'm still on the fence is that I think there's more value in the UNIX style 'discrete commands' model, whether it's WASM or RISC-V I don't think anybody cares, but it's much more about self-describing interfaces with discoverability that can be glued together using whatever tools you have at your disposal. A bit hard to understand here the difference you were intending between discrete commands and a self-describing interface, could you explain? I'd also argue that WASM + Component Model/WASI as a (virtual) instruction set versus RISC-V are very different!
  - pjmlp 2y ago
    DLLs already run everywhere since CLR became cross platform. Really this is walking an already trailed path, multiple times, we can even notice the parts grass no longer grows, how much it has been walked through. https://en.m.wikipedia.org/wiki/UNCOL https://en.m.wikipedia.org/wiki/UNCOL
    - afiori 2y ago
      The "universal compile target" facet of wasm is much less focal than the "universally embeddable" one. The sandboxing is the keystone holding up the entire wasm ecosystem, without it no one would be interested in it same as nobody would run javacript in browsers without a sandbox (we used to, it was called flash, we no longer do). I am curious why you focus so much on "universal runtime/compile-target do fail" rather than its actual strenght when at least in the case of java applet they failed because their sandbox sucked (and startup times).
nindalf 2y ago
> The sandboxing abilities of WASM are near unmatched, along with it's startup time and execution speed compared to native. Could you expand on this? I think everyone would agree with the first two of these - sandboxing is the whole point of WASM, so it would be excellent at that. And startup latency matters a great deal to WASM programs, again not surprised that runtimes have optimised that. But execution speed compared to native? Are you saying WASM programs execute faster than native? Or even at the same speed?
- hardwaresofton 2y ago
  Ah this could have been clearer -- the context is userland emulation (and I expand that to broadly mean emulation/VMs and even containers -- i.e. the current group of options). It's not that Wasm is likely to run faster than native, it's that it runs reasonably close to native speed when compared to the other options. Separately, it also matters what you consider "native" -- it is possible to write programs in a more efficient language (ex. one without a runtime), apply reasonable optimizations, and with AOT/JIT be faster than what could be reasonably written idiomatically in the host language (e.g. some library that already exists to do X but just does it inefficiently).
titzer 2y ago
> the downside is that it means you have to re-invent the world to work with this flavor of runtime. This is at least one of the reasons we've been building thin kernel interfaces for Wasm. We've built two now, one for the Linux syscall interface (https://github.com/arjunr2/WALI https://github.com/arjunr2/WALI) and one for Zephyr. A preliminary paper we wrote a year or so back is here (https://arxiv.org/abs/2312.03858 https://arxiv.org/abs/2312.03858), and we have a new one coming up in Eurosys 25. One of the advantages of a thin kernel interface to something like Linux is really low overhead and low implementation burden for Wasm engines. This makes it easier to then build things like WASI just one level up, compiled against the kernel interface and delivered as a Wasm module. Thus a single WASI implementation can be reused across engines.
- yencabulator 2y ago
  > One of the advantages of a thin kernel interface to something like Linux is really low overhead and low implementation burden for Wasm engines. Such a low burden that both Google (gVisor) and Microsoft (WLS1) failed at it!
  - titzer 2y ago
    A thin kernel interface isn't a reimplementation of a kernel. The WALI implementation in WAMR is ~2000 lines of C, most of which is just pass-through system calls.
    - yencabulator 2y ago
      Okay, so you mean forwarding the syscalls, not implementing them, and thus throwing away the wasm sandbox.
      - titzer 2y ago
        It does not throw away the Wasm sandbox. Sandboxing means two things: memory sandboxing and system sandboxing. It retains the former. For the latter you can apply the same kinds of sandboxing policies as native processes and achieve the same effect, or even do it more efficiently in-process by the engine, and do interposition and whitelist/blacklisting more robustly than, e.g. seccomp.

quesomaster9000 2y ago

I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell. There are a few niches where standardization of interfaces and discoverability will be extremely valuable in terms of interoperability and reducing the development effort to bring-up products that deeply integrate with many things, where currently each team has to re-invent the wheel again for every end-user product they integrate with, with the more ideal alternative being that each product provides their own implementations of the standard interfaces that are plugged into interfaces. But, the reason I'm still on the fence is that I think there's more value in the UNIX style 'discrete commands' model, whether it's WASM or RISC-V I don't think anybody cares, but it's much more about self-describing interfaces with discoverability that can be glued together using whatever tools you have at your disposal.

hardwaresofton 2y ago
> I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell. I think we can at least say WebAssembly + WASI is distinct from DLL hell because at the very least your DLLs will run everywhere, and be intrinsically tied to a version and strict interface. These are things we've just never had before, which is what makes it "different this time". Having cross-language runnable/introspectable binaries/object files with implicit descriptions of their interfaces that are this approachable is new. You can't ensure semantics are the same but it's a better place than we've been before. > But, the reason I'm still on the fence is that I think there's more value in the UNIX style 'discrete commands' model, whether it's WASM or RISC-V I don't think anybody cares, but it's much more about self-describing interfaces with discoverability that can be glued together using whatever tools you have at your disposal. A bit hard to understand here the difference you were intending between discrete commands and a self-describing interface, could you explain? I'd also argue that WASM + Component Model/WASI as a (virtual) instruction set versus RISC-V are very different!
- pjmlp 2y ago
  DLLs already run everywhere since CLR became cross platform. Really this is walking an already trailed path, multiple times, we can even notice the parts grass no longer grows, how much it has been walked through. https://en.m.wikipedia.org/wiki/UNCOL https://en.m.wikipedia.org/wiki/UNCOL
  - afiori 2y ago
    The "universal compile target" facet of wasm is much less focal than the "universally embeddable" one. The sandboxing is the keystone holding up the entire wasm ecosystem, without it no one would be interested in it same as nobody would run javacript in browsers without a sandbox (we used to, it was called flash, we no longer do). I am curious why you focus so much on "universal runtime/compile-target do fail" rather than its actual strenght when at least in the case of java applet they failed because their sandbox sucked (and startup times).

nindalf 2y ago

> The sandboxing abilities of WASM are near unmatched, along with it's startup time and execution speed compared to native. Could you expand on this? I think everyone would agree with the first two of these - sandboxing is the whole point of WASM, so it would be excellent at that. And startup latency matters a great deal to WASM programs, again not surprised that runtimes have optimised that. But execution speed compared to native? Are you saying WASM programs execute faster than native? Or even at the same speed?

hardwaresofton 2y ago
Ah this could have been clearer -- the context is userland emulation (and I expand that to broadly mean emulation/VMs and even containers -- i.e. the current group of options). It's not that Wasm is likely to run faster than native, it's that it runs reasonably close to native speed when compared to the other options. Separately, it also matters what you consider "native" -- it is possible to write programs in a more efficient language (ex. one without a runtime), apply reasonable optimizations, and with AOT/JIT be faster than what could be reasonably written idiomatically in the host language (e.g. some library that already exists to do X but just does it inefficiently).

titzer 2y ago

> the downside is that it means you have to re-invent the world to work with this flavor of runtime. This is at least one of the reasons we've been building thin kernel interfaces for Wasm. We've built two now, one for the Linux syscall interface (https://github.com/arjunr2/WALI https://github.com/arjunr2/WALI) and one for Zephyr. A preliminary paper we wrote a year or so back is here (https://arxiv.org/abs/2312.03858 https://arxiv.org/abs/2312.03858), and we have a new one coming up in Eurosys 25. One of the advantages of a thin kernel interface to something like Linux is really low overhead and low implementation burden for Wasm engines. This makes it easier to then build things like WASI just one level up, compiled against the kernel interface and delivered as a Wasm module. Thus a single WASI implementation can be reused across engines.

yencabulator 2y ago
> One of the advantages of a thin kernel interface to something like Linux is really low overhead and low implementation burden for Wasm engines. Such a low burden that both Google (gVisor) and Microsoft (WLS1) failed at it!
- titzer 2y ago
  A thin kernel interface isn't a reimplementation of a kernel. The WALI implementation in WAMR is ~2000 lines of C, most of which is just pass-through system calls.
  - yencabulator 2y ago
    Okay, so you mean forwarding the syscalls, not implementing them, and thus throwing away the wasm sandbox.
    - titzer 2y ago
      It does not throw away the Wasm sandbox. Sandboxing means two things: memory sandboxing and system sandboxing. It retains the former. For the latter you can apply the same kinds of sandboxing policies as native processes and achieve the same effect, or even do it more efficiently in-process by the engine, and do interposition and whitelist/blacklisting more robustly than, e.g. seccomp.