6 ms·
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
by 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.
- flohofwoe 2y agoI'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).