If you have used WASI in the past, can you mention your use case? Very curious if you found it to give you an edge compared to other sandboxing like containers or VMs.
[flagged]
WASI 0.3
31–40 of 103 posts
Re: WASI 0.3
#32Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…
I disagree. We shouldn't just be copying Unix until the end of time.
Re: WASI 0.3
#33If you have used WASI in the past, can you mention your use case? Very curious if you found it to give you an edge compared to other sandboxing like containers or VMs.
In-process sandboxed llm-generated code execution. Considerably lighter weight, faster to boot (assuming pre-compilation) than Docker or spinning up micro-VMs.
Re: WASI 0.3
#34Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…
I agree. This is saddening. It seems to often happen in "standard first" scenarios for some reason. I was very happy when CloudABI and POSIX were picked as prior art inspiration.
Now it feels like it moved from "what would we need to get things done and achieve our goals?" to "what could be done and which goals could we achieve?"
Maybe I am missing something, but are the recent changes something that people requested?
Re: WASI 0.3
#35Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…
i don't think people calling it CORBA-like are doing it in good faith, but regardless, no we should not do unix apis everywhere for the rest of time please
Re: WASI 0.3
#36Will WebAssembly ever achieve a real breakthrough? It's been almost 10 years since it came around. HTML, CSS and JavaScript were a breakthrough back in the days. WebAssembly still is not right now; only very few folks or companies use it.
I think I've seen you comment this on every recent WASM post, and I'm really wondering what you think breakthrough success looks like for a low-level technology like WASM?
Do you expect everyone to hand-code their websites in WASM? Do you expect every webapp be cross-compiled to WASM?
From where I'm standing, WASM is extremely successful in its specific niches: in enabling islands of high-performance in otherwise web-based software, and in sandboxing plugins to native apps/servers.
Re: WASI 0.3
#37Earlier quoted context omitted.
It's already a breakthrough in my opinion. Many things are possible that weren't possible before. For example, I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web: https://github.com/modulovalue/dart-live it supports hot reload and many other cool features. It runs essentially everywhere and it's a very bare proof of concept for a fully integrated programming development sys…
> I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web Is this really a representative use-case of WASM/WASI? Would'n it be much better to compile Dart to WASM (the Dart SDK even supports "dart compile wasm")?
this is a confusing question; why would it be much better to e.g. compile a C program for x86 linux musl but not the C compiler?
Re: WASI 0.3
#38Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…
I disagree. We shouldn't just be copying Unix until the end of time.
less copying and more keeping in the spirit of, as it has clearly shown it is a model that is built to last
Re: WASI 0.3
#39Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…
The component model is what unlocks relatively type-safe interop between modules written in different languages. Given that Wasm is a runtime target for many languages, this is an entirely appropriate and useful goal.
If you have a host system where you want to expose APIs in an language-agnostic way, IDLs are the best way to do that.
You're also conflating the core WebAssembly work with the WASI work. There is some overlap in people, but WASI is developed separately.
Re: WASI 0.3
#40Love/hate with this one. How was I supposed to follow this? I tried, and few things were publicly visible for nearly two years. I last checked in march and it looked like no progress had been made. That makes me very suspicious of wasiv3. Funny enough, I already implemented a bunch of the promises (pun not intended) and think that freestanding wasm with custom integrations is the more likely future. The promise of wa…
I don't think it's fair to say this work has happened in the shadows. I work on CNCF wasmCloud, and I know how hard we try to make this content available. - Many standing meetings organized around SIGs, all on the public community calendar: https://calendar.google.com/calendar/u/0/newembed?src=events... - A dedicated Zulip: https://bytecodealliance.zulipchat.com/ - Conferences organized around exactly these topics: W…
> - "What is a Component (and Why)?" (WasmCon 2023): https://www.youtube.com/watch?v=tAACYA1Mwv4
At 18:00 the speaker states something like "It should not be Systems Interface but Standard Interfaces" which honestly sounds like a different project. As an implementer or even as just a user in general, can it be trusted that tomorrow it isn't something completely different? Seems like an odd standard to follow.
(EDIT and aside: Rereading this it reads more dismissive than I meant it. So if this isn't clear: I want WASI to succeed. I think having a widely used system interface is great, but I think many know standards that suffered from scope creep. And while big successful standards for better or for worse at least have a chance of surviving this, WASI as the 0.3 indicates is in its infancy. So I worry about it turning out bad, leading to people abandoning the idea altogether or the standard losing sight of its initial goal. So while this is criticism the only reason I bother to write it in first place is because I badly want it to succeed. I worry that if WASI tries to do too much at once - and I totally understand wanting to do that - it makes it less likely to be successfully implemented and thereby less likely to succeed as a standard.)