5 ms·

I'm a WASM fanboy and cheerleader as anyone, all the way back before asm.js was even an idea and Emscripten was one of the weirder ways to make C code run in br

I'm a WASM fanboy and cheerleader as anyone, all the way back before asm.js was even an idea and Emscripten was one of the weirder ways to make C code run in browsers (https://floooh.github.io/2012/10/23/mea-culpa.html https://floooh.github.io/2012/10/23/mea-culpa.html). So far, that whole endeavour made perfect sense to me, one small evolutionary improvement on top of another (even the switch from asm.js to wasm was evolutionary from the pov of the user, you just provided a different compiler switch, and you got wasm output instead of asm.js which ran at the same or slightly better speed). WASI 0.1 was another evolutionary step that made total sense. It had a clear and simple mission: "provide a POSIX compatibility layer for WASM blobs". Very easy to communicate, very easy to use. You just write against (a subset of) the POSIX API and you get a WASM blob that runs on every WASM runtime that provides WASI compatibility, and providing full WASI compatibility wasn't all that hard, more or less just map to existing POSIX calls of the underlying platform. But with WASI 0.2 I have for the very first time in 12 years the impression that the involved people are straying away from the successful evolutionary approach into architecture astronaut territory (and I have never seen that end well). WASI 0.2 (0.3, etc...) should just be small improvements over WASI 0.1: better POSIX compatibility. But with 'actual' WASI 0.2 I don't even know what it's supposed to be despite trying to keep up, it certainly can't be described in a single sentence except "it's awesome, just educate yourself!" - well I tried and I'm just as clueless as before. The problems it apparently wants to solve are nothing I care about (which isn't the case for WASI 0.1 which solves a very important problem for me). What would be important to me in the near future is being able to run WASI 0.1 blobs on any popular desktop operating system without having to install a 3rd party runtime, a hard nut to crack of course because it requires getting Microsoft, Apple and probably even Linus on board - and the more complex WASI becomes, the less likely such a thing is. Meanwhile, there's a real need to improve the POSIX compatibility of WASI 0.1 (for instance currently there's no concept of a current working directory for instance, but a lot of POSIX code depends on this). Instead I get the impression that the WASI project has been hijacked and is being turned into something entirely different, with the original mission to provide a POSIX compatibility layer just being a little appendix that will soon be forgotten (apparently that appendix is now called 'wasi-libc'). I can only offer this advice: it would be better to take all the things that are not related to POSIX compatibility out of WASI and into a new project under a new name (maybe WASCOM or smth dunno...) and clearly mark that as "experimental". That would entirely avoid all the backlash and confusion you might currently be seeing, and probably also unblock 'actual' WASI progress (in the sense of improving POSIX compatibility).

nilslice 2y ago
This is a very well stated and accurate depiction of how wasm has evolved over the years & I couldn’t agree more with your recommendation. WASI 0.1 should really be improved however necessary to increase secure POSIX compatibility— I think it’s already good enough, and implemented widely, but would be happy to see more APIs in it as long as it doesn’t sacrifice the security of many use cases of wasm. I agree that WASI 0.2 is too far of a leap from this, creating an entirely new conceptual system in top of wasm, that is not compatible with the standard at all, and will damage the overall wasm ecosystem by fracture. WASI 0.2 and Component Model are Bytecode Alliance projects and should be collocate in their own GitHub org. Associating them in the WebAssembly org is irresponsible and conveys a false alignment with the overall community and reality of Wasm standards.
- jauntywundrkind 2y ago
  I'm sorry I think this is just so sad & lowly. A portability layer for old code seems like such a lowly sad objective, such an incredibly sad unambitious target. I get the want, but letting such a small world dominate would be horrific. It's pathetically unambitious & small. Wasm has not allowed actual inter-language operation at any serious scale. When we use code, it's basically bundled in, and maybe maybe maybe rust can pull in some c code because of it's own ffi, but that's as much as you get. That will never ever lead to wasm being a broad ecosystem. Everything will be its own distinct thing forever, and that's not a web assembly module if it so drastically fails to get anywhere near any modularity asks. These small minded asks & desires should not outshadow real ambition. For a practical view of what we should be hoping for, the famous Steve Sanderson has a demonof three-way language interop using wasi preview2 that would not in any way be remotely conceivable in preview1. Spare us from the retrogressives that argue the shallow short preview1 would be anywhere near enough of a stopping point; that would be absurd. https://youtu.be/p9taQkF24Fs https://youtu.be/p9taQkF24Fs
  - nilslice 2y ago
    No one is saying anyone should stop exploring new paths. I don't know what you personally are bringing to the table as far as adding to the ambition, so excuse my naivety. The issue is that there is a misrepresentation by the Bytecode Alliance about WASI, from where it began, to where it is now. And a lot of this has been poorly communicated or not done at all. Which has only left many of us to think that they are trying to pull a fast one over the community to forcefully bring everyone along into Components when that is not desirable. > Wasm has not allowed actual inter-language operation at any serious scale. This is untrue, and you may just be unaware of efforts like Extism [0]. While it is intentionally not a binding generator, it does make it very easy to blend languages meaningfully. Disclaimer, I work on Extism and therefore have some bias :) We have different goals than the Component Model, so if you actually want what the component model offers, you should use it! I believe the easy solution here is to: 1. stop referring to WASI 0.1 as "legacy", implying some obsolete status, or call 0.1 something entirely different. Let it continue to be an easily targetable interface to bridge to the rest of today's software. 2. move WASI and Component Model code repositories out of the WebAssembly github org. This would clarify the distinction between WebAssembly (the standard) and WASI 0.2 / WIT / CM as a project by Bytecode Alliance. They are not the same, and while the Bytecode Alliance works on making things usable and ready, it doesn't cause harm or confusion for WebAssembly users. [0]: https://github.com/extism/extism https://github.com/extism/extism

nilslice 2y ago

This is a very well stated and accurate depiction of how wasm has evolved over the years & I couldn’t agree more with your recommendation. WASI 0.1 should really be improved however necessary to increase secure POSIX compatibility— I think it’s already good enough, and implemented widely, but would be happy to see more APIs in it as long as it doesn’t sacrifice the security of many use cases of wasm. I agree that WASI 0.2 is too far of a leap from this, creating an entirely new conceptual system in top of wasm, that is not compatible with the standard at all, and will damage the overall wasm ecosystem by fracture. WASI 0.2 and Component Model are Bytecode Alliance projects and should be collocate in their own GitHub org. Associating them in the WebAssembly org is irresponsible and conveys a false alignment with the overall community and reality of Wasm standards.

jauntywundrkind 2y ago
I'm sorry I think this is just so sad & lowly. A portability layer for old code seems like such a lowly sad objective, such an incredibly sad unambitious target. I get the want, but letting such a small world dominate would be horrific. It's pathetically unambitious & small. Wasm has not allowed actual inter-language operation at any serious scale. When we use code, it's basically bundled in, and maybe maybe maybe rust can pull in some c code because of it's own ffi, but that's as much as you get. That will never ever lead to wasm being a broad ecosystem. Everything will be its own distinct thing forever, and that's not a web assembly module if it so drastically fails to get anywhere near any modularity asks. These small minded asks & desires should not outshadow real ambition. For a practical view of what we should be hoping for, the famous Steve Sanderson has a demonof three-way language interop using wasi preview2 that would not in any way be remotely conceivable in preview1. Spare us from the retrogressives that argue the shallow short preview1 would be anywhere near enough of a stopping point; that would be absurd. https://youtu.be/p9taQkF24Fs https://youtu.be/p9taQkF24Fs
- nilslice 2y ago
  No one is saying anyone should stop exploring new paths. I don't know what you personally are bringing to the table as far as adding to the ambition, so excuse my naivety. The issue is that there is a misrepresentation by the Bytecode Alliance about WASI, from where it began, to where it is now. And a lot of this has been poorly communicated or not done at all. Which has only left many of us to think that they are trying to pull a fast one over the community to forcefully bring everyone along into Components when that is not desirable. > Wasm has not allowed actual inter-language operation at any serious scale. This is untrue, and you may just be unaware of efforts like Extism [0]. While it is intentionally not a binding generator, it does make it very easy to blend languages meaningfully. Disclaimer, I work on Extism and therefore have some bias :) We have different goals than the Component Model, so if you actually want what the component model offers, you should use it! I believe the easy solution here is to: 1. stop referring to WASI 0.1 as "legacy", implying some obsolete status, or call 0.1 something entirely different. Let it continue to be an easily targetable interface to bridge to the rest of today's software. 2. move WASI and Component Model code repositories out of the WebAssembly github org. This would clarify the distinction between WebAssembly (the standard) and WASI 0.2 / WIT / CM as a project by Bytecode Alliance. They are not the same, and while the Bytecode Alliance works on making things usable and ready, it doesn't cause harm or confusion for WebAssembly users. [0]: https://github.com/extism/extism https://github.com/extism/extism