Earlier quoted context omitted.
Yes, that is a common section in computing papers.
WASI isn't an academic paper.
WASI 0.2.0 and Why It Matters
61–70 of 110 posts
Re: WASI 0.2.0 and Why It Matters
#62I really want polyglot programming to become easier. What are the barriers remaining for wasm/wasi to provide a foundation for a truly polyglot FFI? It seems like it was the promise from the beginning, but I lost track a long time ago.
As recommended elsewhere in the comments, there's a pretty damned fine talk my Luke Wagner that covers wasm components & the promise. He talks about cross-platform was 18m35s in: https://youtu.be/tAACYA1Mwv4#t=18m35s
Re: WASI 0.2.0 and Why It Matters
#63About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me. I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical p…
Might be part of the nerd kingdom for you, but I recently made pretty cool use of WASM+WASI in a VSCode extension: https://floooh.github.io/2023/12/31/vscode-wasm-wasi.html Also quite a few 'CPU nerds' found my 'visual6502 remixes' useful so far: https://floooh.github.io/visual6502remix/ https://floooh.github.io/visualz80remix/ Development experience with Emscripten and WASI SDK is fine really (in the sense that thes…
Not quite the same, but tangentially related since we're talking WASM+WASI and VSCode extensions - I have high hopes for the vscode-wasm[1] project. The VSCode extension host is a massive hog, and this seems like a big step in the right direction.
[0]: https://floooh.github.io/2023/11/11/emscripten-ide.html [0]: https://github.com/microsoft/vscode-wasm
Re: WASI 0.2.0 and Why It Matters
#64I really want polyglot programming to become easier. What are the barriers remaining for wasm/wasi to provide a foundation for a truly polyglot FFI? It seems like it was the promise from the beginning, but I lost track a long time ago.
Re: WASI 0.2.0 and Why It Matters
#65Earlier quoted context omitted.
The WebAssembly standard breaks into two parts, "core WASM" which is the spec the browsers use and everyone else. Then in the non-browser space there is WASI (system interface specification). The WASI-Preview 2 standard uses component model as the underlying mechanism for implementing the APIs it supports. It is not compatible with existing WASI functions... you need to change your binary with an adapter to get exist…
Ooof, that sounds like a mess tbh (traditionally, WASI could be described as "POSIX for WASM", and IMHO this sort of focus was just right, easy to communicate, easy to use). When reading through all the things going into WASI Preview 2 (basically "everything and the kitchen sink", except for async/await(!) which goes into Preview 3) my first thought was: ok, this is what the second-system-effect looks like in practic…
Re: WASI 0.2.0 and Why It Matters
#66About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me. I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical p…
So..... think of it this way: HTML was built for the "internet", but works just as well for plain local files (eg: file:///one.html => file:///two.html). JS was added to HTML, and much gnashing of teeth ensued. JS (minified), HTML (generated), CSS (compiled), Flash, Java Applets, etc... move away from the "original" internet (Hyper-Text DOCUMENTS) into Web2.0 "Apps" and Web3.0 "Walled Gardens". What if instead of shi…
I looked into this and... holy crap! We are there. Not for modern programs quite yet, sure, but this is amazing. You can use Windows 2000 from your browser, running inside an x86 emulator for WASM.
Re: WASI 0.2.0 and Why It Matters
#67Earlier quoted context omitted.
For folks looking to learn more, the Component Model documentation is pretty good! I like this excerpt for explaining the core vs component split: > components interact only through the Canonical ABI. Specifically, unlike core modules, components may not export Wasm memory. This not only reinforces sandboxing, but enables interoperation between languages that make different assumptions about memory - for example, all…
Hopefully it's trivial to push C structs around by value if poking around in other instances memory isn't allowed. Otherwise it sounds like a lot of hassle just to appease "fringe languages" ( ;P ) that don't have a linear memory model. This sort of "directly reading and writing the WASM heap" is quite essential for JS code that sits between a WASM instance and a web API for instance (in the "WASM in browsers" scenar…
Re: WASI 0.2.0 and Why It Matters
#68Re: WASI 0.2.0 and Why It Matters
#69Earlier quoted context omitted.
Thanks for sharing. I often wondered why we didn’t just create a subset of POSIX for the web and wasm, this seems to answer my questions.
Other team ask themselves that question and created WASIX. I'm looking into it. Because to me it seems only logical, to have POSIX that can work on the web.
Re: WASI 0.2.0 and Why It Matters
#70Sadly, still no Framebuffer API for WASI GUI apps ( https://github.com/WebAssembly/WASI/issues/174 ).
I have always suspected that sort of thing is somehow blocked by Google because it would make mean web assembly runtimes don't need web browsers. Although now that there is actually a significant update to WASI, perhaps it's possible that they are just actually that slow? Or maybe both are true. Probably I am just a "conspiracy nut". I mean I definitely am, but in this case it might just be paranoia.
At the end of 2023 we counted around 40 contributors who have been working on WASI specifications and implementations: https://github.com/WebAssembly/meetings/blob/main/wasi/2023/... . That is a great growth for our project from a few years ago when that issue was filed, but as you can see from what people are working on, its all much more foundational pieces than a graphics interface. Also, if you look at who is employing those contributors, its largely vendors who are interested in WASI in the context of serverless. That doesn't mean WASI is limited to only serverless, but that has been the focus from contributors so far.
By rolling out WASI on top of the WASM Component Model we have built a sound foundation for creating WASI proposals that support more problem domains, such as embedded systems (@mc_woods and his colleagues are helping with this), or graphics if someone is interested in putting in the work. Our guide to how to create proposals is found here: https://github.com/WebAssembly/WASI/blob/main/Contributing.m... .