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
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.
"This first part of this article discusses creating language-independent components, that is, components that can be consumed by apps that are written in any language. You can also create a single component or app from source code written in multiple languages; see Cross-Language Interoperability in the second part of this article."
From "Language independence and language-independent components" in MSIL, originally published in 2001.
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).
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).
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.
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
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.
I have no idea what the people guiding WASI are motivated about, but for sure it doesn't seem aligned with the community motivations... which might be hurting the ecosystem in the long run.
For the exact reasons the parent comment mentioned, at Wasmer we aimed for full POSIX compatibility as part of WASIX (a superset of WASI 0.1): https://wasix.org/. WASIX has support for many syscalls not available in WASI: fork, exec, longjmp, setjmp, threads, sockets, and many more.
It's insightful to know that many people, and specially those close to the Bytecode Alliance, neglected the contributions, and try to push down the project, and even tried to make us rename it: https://github.com/wasix-org/cargo-wasix/issues/4
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
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.