7 ms·

WASI 0.3

260 points by mavdol04 3mo ago

https://github.com/WebAssembly/WASI/releases/tag/v0.3.0 https://github.com/WebAssembly/WASI/releases/tag/v0.3.0

shevy-java 3mo ago
Will 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.
- grufkork 3mo ago
  I mean, it’s another tool. It doesn’t really make an entirely new kind of web app possible, but it’s useful for some specific compute-heavy tasks (with limitations like JS<->WASM being slow). It’s also useful for running not-JS in the browser; I’m building a lighting console with a web UI distributed over multiple devices, and being able to use the exact same structs/representation and algorithms on server and client is pretty neat. It’s like Node, but in reverse! But none of this is cause for paradigm shift, so I don’t think seeing a ”breakthrough” really is relevant.
- __s 3mo ago
  It has, but its usually just an optimization, so goes unnoticed
- CGamesPlay 3mo ago
  I think its killer use case is actually embedded in non-web places. Tree Sitter parsers require arbitrary programs to be able to parse arbitrary languages. WebAssembly is a natural way to achieve that: write your parser in any language, compile to WebAssembly, use that result in any supported editor. You get sandboxed execution and arbitrary compute. It has to compete with more domain-adapted use cases though. Does WASM make more sense than eBPF for packet filtering? It doesn't seem to make more sense than JavaScript for making websites. Maybe it makes more sense for deploying edge services (which IIUC is the main use case for WASI).
  - wongarsu 3mo ago
    Plugin architectures are a niche where WASM really shines. Before WASM most plugins were either high performance (loading dynamic libraries) or sandboxed and safe for untrusted plugins (LUA etc). WASM allows you to have your cake and eat it to. You pay with a bit of complexity, but it's in a great and somewhat unique place in the tradeoff space
- modulovalue 3mo ago
  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 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 system. The problem is that things just take time if you have to coordinate across a bunch of languages and teams while trying to make everyone happy. To give you a sense of what else is coming: the wasm ecosystem is moving towards supporting a component model. Eventually you'll be able to import any piece of code from any programming language that supports it. Wasm interface types will make that possible.
  - Rochus 3mo ago
    > 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")?
    - throawayonthe 3mo ago
      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?
      - Rochus 3mo ago
        Your analogy doesn't quite hold. The primary use case of a compilation target is to compile programs, not the compiler itself. With Dart specifically, "dart compile wasm" already exists precisely for that purpose. Compiling the entire Dart VM (a multi-hundred-thousand-line C++ codebase) to Wasm and then running Dart inside that is a clever in-browser IDE trick, but it's heavy, indirect, and not what Wasm/WASI was designed to showcase. It also sidesteps WasmGC, which is exactly the kind of Wasm evolution that makes Dart-to-Wasm compelling.
- OtomotO 3mo ago
  WASI stands for WebAssembly System Interface. It has little to do with the webassembly in the browser. I use it to extend a native application, for example. No browser in sight at all.
- artemonster 3mo ago
  for me its undebuggability. -"hey, look at our C Rust FORTRAN to WASM translator, blahblah" -"uhm, cool, how do I debug it?" -"yeah...about that...you cant!"
  - fsloth 3mo ago
    This! The only way to get to a stable system at least with c/c++ source, where you can hunt bugs, is to have a fairly large unit test coverage. When something fails - add that as test case; run ctest - pray that this is discoverable with tests. So wasm is a really strange compilation target for systems programming languages. I mean there _are_ ways to debug it in a browser but they sort of suck.
  - tdhz77 3mo ago
    Why can’t you?
    - artemonster 3mo ago
      how can you? its running wasm in a browser, how do you see original C/Rust code and or variables
  - phickey 3mo ago
    Wasmtime implements a remote debugging server, so that you can debug guest programs with a recent build of LLDB. Set breakpoints based on the source language symbols, single-step through wasm opcodes, anything you'd expect: https://docs.wasmtime.dev/examples-debugging-guest.html https://docs.wasmtime.dev/examples-debugging-guest.html
    - artemonster 3mo ago
      still useless. I had an idea to offload parts of my game core into wasm leaving only UI in the browser - I abandoned that idea when there was absolutely zero possibility for me to debug in browser what is wrong with my core. i just rewrote everything to TS (from rust)
- lioeters 3mo ago
  You said the exact same thing a couple days ago. You don't know what you don't know. WebAssembly has been a great success thanks to its excellent initial design.
- kettlecorn 3mo ago
  WebAssembly is used in all sorts of ways. It's used heavily by major web apps like Figma, it's used to run non-Javascript languages on Cloudflare Workers, many compute-heavy web libraries rely on Wasm modules, many web games rely on Wasm, it's used for safe plugins in some native apps like Microsoft Flight Simulator, amongst other use cases.
- callahad 3mo ago
  It's a silent technology, but I'd argue it has broken through in that most of us already use it daily without knowing. Figma, Google Sheets, Disney+, Prime Video, and much more all have WebAssembly somewhere in their stack.
- bearjaws 3mo ago
  I'm building a game where you learn to program golang or python and it all runs in webassembly, this way any student chromebook can just pick up and go. That feels pretty revolutionary, no need to setup your local system to get core concepts. Even have plans to use postgres in WASM (pglite), and I know a few real time apps use sqlite in WASM.
- Dwedit 3mo ago
  WebAssembly doesn't beat JavaScript in performance, and that is embarrassing.
  - kettlecorn 3mo ago
    That's not accurate. I Googled for a recent performance benchmark and found this which indicates Wasm offers a notable performance gain: https://medium.com/@hashbyt/webassembly-vs-javascript-performance-b2936d4c6c03 https://medium.com/@hashbyt/webassembly-vs-javascript-perfor...
    - Dwedit 3mo ago
      My task in question was a number crunching task, basically doing multiply-and-add for 336-bit integers. I wrote a JS version, and a C version compiled into WASM by using Zig. You'd think that WebAssembly would trounce JS here, but it actually didn't. The JS code had been written carefully to avoid allocations, and also avoiding the built-in JavaScript BigInt. I rolled my own BigInt instead using an array of numbers. Each number, despite being a double, was basically a 48-bit integer. Long multiplication requires splitting a 48-bit integer into two 24-bit integers so an intermediate multiplication result will fit in 48 bits. The C version used 32x32=64-bit integer math. (Would have been nice if WASM had supported 64x64=128-bit multiplication) Even with the overhead of using doubles instead of integers, the JavaScript and C versions ran at nearly the same speed. I think the C version was slightly faster, but not significantly. The C version took a lot longer to load, as it had to instantiate a Webassembly object, and had to run glue code to copy things in and out of Webassembly memory.
      - jason_oster 3mo ago
        > and had to run glue code to copy things in and out of Webassembly memory. Not surprising. The FFI boundary is always a bottleneck. If you can eliminate it, you will see where the WASM JIT shines. You have far more control over mechanical sympathy with C/WASM than JavaScript (though far from perfect). Also, consider publishing your findings and ask for reviews for optimization opportunities.
- swiftcoder 3mo ago
  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.
simonw 3mo ago
If you don't want to download the .tar.gz I think you can browse the content for this release (.wit interface files) here on GitHub: https://github.com/WebAssembly/WASI/tree/v0.3.0/proposals https://github.com/WebAssembly/WASI/tree/v0.3.0/proposals
b33j0r 3mo ago
Love/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 wasi components has not been fulfilled. The market wants to hotload and link artifacts dynamically. The wasi project requires insider wizardry to use it that way: the offering has been statically linking components before you ship. Defeating 99% of the use cases. I do not like that this has been worked on in the shadows.
- airstrike 3mo ago
  It's version 0.3...
- hectaman 3mo ago
  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@bytecodealliance.org https://calendar.google.com/calendar/u/0/newembed?src=events... - A dedicated Zulip: https://bytecodealliance.zulipchat.com/ https://bytecodealliance.zulipchat.com/ - Conferences organized around exactly these topics: Wasm Day, WasmCon, Wasm I/O, and the Bytecode Alliance Plumbers Summit - CNCF projects: wasmCloud, Spin - Blogs, many with recordings, summaries, and transcripts: https://bytecodealliance.org/articles/the-road-to-component-model-1-0 https://bytecodealliance.org/articles/the-road-to-component-..., https://wasmcloud.com/community/ https://wasmcloud.com/community/, https://spinframework.dev/blog/index https://spinframework.dev/blog/index If you want the architectural direction straight from the source, Luke Wagner's keynotes are the best place to start: - "What is a Component (and Why)?" (WasmCon 2023): https://www.youtube.com/watch?v=tAACYA1Mwv4 https://www.youtube.com/watch?v=tAACYA1Mwv4 - "The Path to Components": https://www.youtube.com/watch?v=phodPLY8zNE https://www.youtube.com/watch?v=phodPLY8zNE - "Towards a Component Model 1.0" (Wasm I/O 2026): https://www.youtube.com/watch?v=qq0Auw01tH8 https://www.youtube.com/watch?v=qq0Auw01tH8 I mean this, though - what else would you like to see to try and make the content and process more accessible? Are there communities that are doing this really well that we could use for inspiration?
lifty 3mo ago
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.
- OtomotO 3mo ago
  extending software with a plugin system
- tdhz77 3mo ago
  Edge rural farm systems
- utopiah 3mo ago
  I tinkered with https://extism.org https://extism.org and basically the use case is that they suggest, namely you can extend software in another programming language but without having to setup a container or VMs on the client. They "just" run the code in the browser and it can be JavaScript, sure, but can also be Python, Go, whatever. It's quite specific though as I'm working on support programming in the browser. If you are not deep into letting a very specific kind of user extend, it's probably overkill. Even then it's a very VERY niche thing because it has to be simultaneously : - someone who is opinionated about a programming language (either because they know too much, i.e. expert, or not enough, i.e beginner) - is dedicated enough to want to try to build something on top of an existing system - does not want to bother with solutions you mentioned
  - pie_flavor 3mo ago
    We evaluated Extism and concluded that it did basically nothing that WASI and the component model didn't already do out of the box. Was your experience different?
- airstrike 3mo ago
  Extending my Rust binary with a marketplace of WASM-based extensions like VSCode
- jedisct1 3mo ago
garganzol 3mo ago
Wrong 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 main purpose of providing easy interoperability between different ecosystems is totally lost. I do not know why WebAssembly committee thinks that shoving-in CORBA-like monstrosity is even an acceptable idea. Let's keep WebAssembly lean and fast! Anything extra can (and should) be implemented by other technologies.
- IshKebab 3mo ago
  I disagree. We shouldn't just be copying Unix until the end of time.
  - iqihs 3mo ago
    less copying and more keeping in the spirit of, as it has clearly shown it is a model that is built to last
    - IshKebab 3mo ago
      It clearly hasn't, if you've been paying any attention to security. The Unix security model is that all code that a user runs is 100% trusted. That's absurd in today's world.
    - Ericson2314 3mo ago
      That's like saying "the US Constitution has clearly shown it's a model that is built to last" Sometimes bad designs stick around due to pure inertia
      - tete 3mo ago
        Even if something lasts due to pure inertia it lasts. And something that lasts is pretty nice if you want a standard to last, or be implemented. The standard usually isn't the thing that you use to proof you can do something better, by being different. Because then everyone will have a harder time adapting it. People implement interfaces they dislike. Since this is related to Webassembly, Browsers, the Web. The web has a lot of historically baggage, that one might have to work around at times, sometimes more sometimes less. There are good bits and not so good bits and in the end a lot of the time more modern web applications (whether you think they are good or bad) as well as web browsers jump through hoops to do things. For many applications there would be better protocols. But it became the dominant standard, a standard that is actually being used a lot and that is why it has become a success story. It wasn't a hundred times better than everything else. It simply was something that people managed to implement successfully and something where they were willing to deal with shortcomings, because there are great benefits in implementing the same standard as everyone else. Don't know much about the US constitution, but it seems that it was largely good enough to make people work together that otherwise might have ended up fighting each other. That's what you'd get if everyone had a different idea about what a good constitution is. Maybe things are unclear, and maybe there are uproars because of things, but it doesn't even get to that if people don't agree on a standard or a constitution in first place. And while over the years I often imagined how great it would be if everyone just used that better standard that has been there for a long time and nobody uses and is completely forgotten, if it ever had any popularity, then everything would be so much better and greater and I wouldn't have to do that senseless thing I am doing now. But if that standard doesn't allow for people to agree with it by implementing it it's essentially worthless (outside of maybe "prior art" consideration). And like it or not we currently live in a world where designs persist due to pure inertia. But we know that obviously people are willing to implement these which means when a standard comes along that is similar to what already is there then having many people adapting it is realistic. Otherwise it's that super interesting university project that never makes it into anything in the real world.
ilaksh 3mo ago
Is there some Zig code demonstrating how to use all the changes in a Zig program that compiles to WASI 0.3.0?
- jedisct1 3mo ago
  There's https://github.com/ofalkenberg/zig-wasi-components https://github.com/ofalkenberg/zig-wasi-components
yoshuaw 3mo ago
Hey everyone, we just published the announcement post for WASI 0.3 on the Bytecode Alliance blog: https://bytecodealliance.org/articles/WASI-0.3 https://bytecodealliance.org/articles/WASI-0.3 The current link is just the release notes and covers only the interface-level changes. The announcement post goes into more detail on what's new in WASI 0.3, how it differs from WASI 0.2, and includes examples.
- dang 3mo ago
  Ok, I've swapped that link in at the top and put the submitted URL (https://github.com/WebAssembly/WASI/releases/tag/v0.3.0 https://github.com/WebAssembly/WASI/releases/tag/v0.3.0) in the toptext.
  - yoshuaw 3mo ago
    Thank you!
_jsdw 3mo ago
This is funny timing to me, because just the other week I did a dive into WebAssembly and WASI 0.2 (https://jsdw.me/posts/wasm-components/ https://jsdw.me/posts/wasm-components/) and assumed that 0.3 would be a while yet as there was no obvious (to me) sign it would come for a while! Once the tooling is there and Rust has a wasi 0.3 target I'll give it more of a look at :)
mmastrac 3mo ago
I'd love it if WASI modules could introspect their own custom sections (potentially even more introspection than that), but I've never been able to figure out a good way to do this. Seems like a fairly useful feature for a few use cases.
WalterGR 3mo ago
Also see, from yesterday: https://news.ycombinator.com/item?id=48448083 https://news.ycombinator.com/item?id=48448083 “The Road to the WASM Component Model 1.0” (bytecodealliance.org) 95 points | by emschwartz | 99 comments
hmry 3mo ago
Does the stackfull async implementation use the stack-switching proposal? I was under the impression that it's not implemented in most runtimes (very difficult to retrofit into existing implementations), and only available on x86_64 Linux in wasmtime.
- phickey 3mo ago
  No, the stack switching proposal is not used. Stack switching is a set of core Wasm opcodes that permit a guest to change its own stack. Instead of using opcodes inside the Wasm, the stackful async mode of the component model’s ABI calls out into the component model implementation where it can manipulate the stacks with special host powers - JSPI is sufficient on web engines to express this, and wasmtime manages guest stacks in memory. When stack switching becomes available in all engines, it will be possible to implement this part of the component model in pure Wasm without host magic, e.g. web engines will be able to avoid the call out to JS to use JSPI.
  - hmry 3mo ago
    Thank you, that's great to hear. I was worried it would be a long time before most runtimes could use WASIp3 if it required stack-switching.
syrusakbary 3mo ago
Congrats on the release to the WASI team. TL;DR: WASI 0.3.0 is the Component Model-based WASI proposal. It adds async/await-style capabilities such as actors and streams, and today is runnable in only one server-side Wasm runtime (it is not supported natively by browsers). Unfortunately it still breaks compatibility with the original WASI proposal and runtimes that supported it. If your goal is to compile existing, unmodified C/C++ programs and libraries to WebAssembly, WASIX may be a more practical option today ( https://wasix.org/ https://wasix.org/ ). Disclosure: I’m part of Wasmer, the company behind WASIX.
oexside 3mo ago
[flagged]

260 points by mavdol04 3mo ago

https://github.com/WebAssembly/WASI/releases/tag/v0.3.0 https://github.com/WebAssembly/WASI/releases/tag/v0.3.0

Will 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.

grufkork 3mo ago
I mean, it’s another tool. It doesn’t really make an entirely new kind of web app possible, but it’s useful for some specific compute-heavy tasks (with limitations like JS<->WASM being slow). It’s also useful for running not-JS in the browser; I’m building a lighting console with a web UI distributed over multiple devices, and being able to use the exact same structs/representation and algorithms on server and client is pretty neat. It’s like Node, but in reverse! But none of this is cause for paradigm shift, so I don’t think seeing a ”breakthrough” really is relevant.
__s 3mo ago
It has, but its usually just an optimization, so goes unnoticed
CGamesPlay 3mo ago
I think its killer use case is actually embedded in non-web places. Tree Sitter parsers require arbitrary programs to be able to parse arbitrary languages. WebAssembly is a natural way to achieve that: write your parser in any language, compile to WebAssembly, use that result in any supported editor. You get sandboxed execution and arbitrary compute. It has to compete with more domain-adapted use cases though. Does WASM make more sense than eBPF for packet filtering? It doesn't seem to make more sense than JavaScript for making websites. Maybe it makes more sense for deploying edge services (which IIUC is the main use case for WASI).
- wongarsu 3mo ago
  Plugin architectures are a niche where WASM really shines. Before WASM most plugins were either high performance (loading dynamic libraries) or sandboxed and safe for untrusted plugins (LUA etc). WASM allows you to have your cake and eat it to. You pay with a bit of complexity, but it's in a great and somewhat unique place in the tradeoff space
modulovalue 3mo ago
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 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 system. The problem is that things just take time if you have to coordinate across a bunch of languages and teams while trying to make everyone happy. To give you a sense of what else is coming: the wasm ecosystem is moving towards supporting a component model. Eventually you'll be able to import any piece of code from any programming language that supports it. Wasm interface types will make that possible.
- Rochus 3mo ago
  > 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")?
  - throawayonthe 3mo ago
    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?
    - Rochus 3mo ago
      Your analogy doesn't quite hold. The primary use case of a compilation target is to compile programs, not the compiler itself. With Dart specifically, "dart compile wasm" already exists precisely for that purpose. Compiling the entire Dart VM (a multi-hundred-thousand-line C++ codebase) to Wasm and then running Dart inside that is a clever in-browser IDE trick, but it's heavy, indirect, and not what Wasm/WASI was designed to showcase. It also sidesteps WasmGC, which is exactly the kind of Wasm evolution that makes Dart-to-Wasm compelling.
OtomotO 3mo ago
WASI stands for WebAssembly System Interface. It has little to do with the webassembly in the browser. I use it to extend a native application, for example. No browser in sight at all.
artemonster 3mo ago
for me its undebuggability. -"hey, look at our C Rust FORTRAN to WASM translator, blahblah" -"uhm, cool, how do I debug it?" -"yeah...about that...you cant!"
- fsloth 3mo ago
  This! The only way to get to a stable system at least with c/c++ source, where you can hunt bugs, is to have a fairly large unit test coverage. When something fails - add that as test case; run ctest - pray that this is discoverable with tests. So wasm is a really strange compilation target for systems programming languages. I mean there _are_ ways to debug it in a browser but they sort of suck.
- tdhz77 3mo ago
  Why can’t you?
  - artemonster 3mo ago
    how can you? its running wasm in a browser, how do you see original C/Rust code and or variables
- phickey 3mo ago
  Wasmtime implements a remote debugging server, so that you can debug guest programs with a recent build of LLDB. Set breakpoints based on the source language symbols, single-step through wasm opcodes, anything you'd expect: https://docs.wasmtime.dev/examples-debugging-guest.html https://docs.wasmtime.dev/examples-debugging-guest.html
  - artemonster 3mo ago
    still useless. I had an idea to offload parts of my game core into wasm leaving only UI in the browser - I abandoned that idea when there was absolutely zero possibility for me to debug in browser what is wrong with my core. i just rewrote everything to TS (from rust)
lioeters 3mo ago
You said the exact same thing a couple days ago. You don't know what you don't know. WebAssembly has been a great success thanks to its excellent initial design.
kettlecorn 3mo ago
WebAssembly is used in all sorts of ways. It's used heavily by major web apps like Figma, it's used to run non-Javascript languages on Cloudflare Workers, many compute-heavy web libraries rely on Wasm modules, many web games rely on Wasm, it's used for safe plugins in some native apps like Microsoft Flight Simulator, amongst other use cases.
callahad 3mo ago
It's a silent technology, but I'd argue it has broken through in that most of us already use it daily without knowing. Figma, Google Sheets, Disney+, Prime Video, and much more all have WebAssembly somewhere in their stack.
bearjaws 3mo ago
I'm building a game where you learn to program golang or python and it all runs in webassembly, this way any student chromebook can just pick up and go. That feels pretty revolutionary, no need to setup your local system to get core concepts. Even have plans to use postgres in WASM (pglite), and I know a few real time apps use sqlite in WASM.
Dwedit 3mo ago
WebAssembly doesn't beat JavaScript in performance, and that is embarrassing.
- kettlecorn 3mo ago
  That's not accurate. I Googled for a recent performance benchmark and found this which indicates Wasm offers a notable performance gain: https://medium.com/@hashbyt/webassembly-vs-javascript-performance-b2936d4c6c03 https://medium.com/@hashbyt/webassembly-vs-javascript-perfor...
  - Dwedit 3mo ago
    My task in question was a number crunching task, basically doing multiply-and-add for 336-bit integers. I wrote a JS version, and a C version compiled into WASM by using Zig. You'd think that WebAssembly would trounce JS here, but it actually didn't. The JS code had been written carefully to avoid allocations, and also avoiding the built-in JavaScript BigInt. I rolled my own BigInt instead using an array of numbers. Each number, despite being a double, was basically a 48-bit integer. Long multiplication requires splitting a 48-bit integer into two 24-bit integers so an intermediate multiplication result will fit in 48 bits. The C version used 32x32=64-bit integer math. (Would have been nice if WASM had supported 64x64=128-bit multiplication) Even with the overhead of using doubles instead of integers, the JavaScript and C versions ran at nearly the same speed. I think the C version was slightly faster, but not significantly. The C version took a lot longer to load, as it had to instantiate a Webassembly object, and had to run glue code to copy things in and out of Webassembly memory.
    - jason_oster 3mo ago
      > and had to run glue code to copy things in and out of Webassembly memory. Not surprising. The FFI boundary is always a bottleneck. If you can eliminate it, you will see where the WASM JIT shines. You have far more control over mechanical sympathy with C/WASM than JavaScript (though far from perfect). Also, consider publishing your findings and ask for reviews for optimization opportunities.
swiftcoder 3mo ago
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.

simonw 3mo ago

If you don't want to download the .tar.gz I think you can browse the content for this release (.wit interface files) here on GitHub: https://github.com/WebAssembly/WASI/tree/v0.3.0/proposals https://github.com/WebAssembly/WASI/tree/v0.3.0/proposals

b33j0r 3mo ago

Love/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 wasi components has not been fulfilled. The market wants to hotload and link artifacts dynamically. The wasi project requires insider wizardry to use it that way: the offering has been statically linking components before you ship. Defeating 99% of the use cases. I do not like that this has been worked on in the shadows.

airstrike 3mo ago
It's version 0.3...
hectaman 3mo ago
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@bytecodealliance.org https://calendar.google.com/calendar/u/0/newembed?src=events... - A dedicated Zulip: https://bytecodealliance.zulipchat.com/ https://bytecodealliance.zulipchat.com/ - Conferences organized around exactly these topics: Wasm Day, WasmCon, Wasm I/O, and the Bytecode Alliance Plumbers Summit - CNCF projects: wasmCloud, Spin - Blogs, many with recordings, summaries, and transcripts: https://bytecodealliance.org/articles/the-road-to-component-model-1-0 https://bytecodealliance.org/articles/the-road-to-component-..., https://wasmcloud.com/community/ https://wasmcloud.com/community/, https://spinframework.dev/blog/index https://spinframework.dev/blog/index If you want the architectural direction straight from the source, Luke Wagner's keynotes are the best place to start: - "What is a Component (and Why)?" (WasmCon 2023): https://www.youtube.com/watch?v=tAACYA1Mwv4 https://www.youtube.com/watch?v=tAACYA1Mwv4 - "The Path to Components": https://www.youtube.com/watch?v=phodPLY8zNE https://www.youtube.com/watch?v=phodPLY8zNE - "Towards a Component Model 1.0" (Wasm I/O 2026): https://www.youtube.com/watch?v=qq0Auw01tH8 https://www.youtube.com/watch?v=qq0Auw01tH8 I mean this, though - what else would you like to see to try and make the content and process more accessible? Are there communities that are doing this really well that we could use for inspiration?

lifty 3mo ago

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.

OtomotO 3mo ago
extending software with a plugin system
tdhz77 3mo ago
Edge rural farm systems
utopiah 3mo ago
I tinkered with https://extism.org https://extism.org and basically the use case is that they suggest, namely you can extend software in another programming language but without having to setup a container or VMs on the client. They "just" run the code in the browser and it can be JavaScript, sure, but can also be Python, Go, whatever. It's quite specific though as I'm working on support programming in the browser. If you are not deep into letting a very specific kind of user extend, it's probably overkill. Even then it's a very VERY niche thing because it has to be simultaneously : - someone who is opinionated about a programming language (either because they know too much, i.e. expert, or not enough, i.e beginner) - is dedicated enough to want to try to build something on top of an existing system - does not want to bother with solutions you mentioned
- pie_flavor 3mo ago
  We evaluated Extism and concluded that it did basically nothing that WASI and the component model didn't already do out of the box. Was your experience different?
airstrike 3mo ago
Extending my Rust binary with a marketplace of WASM-based extensions like VSCode
jedisct1 3mo ago

garganzol 3mo ago

Wrong 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 main purpose of providing easy interoperability between different ecosystems is totally lost. I do not know why WebAssembly committee thinks that shoving-in CORBA-like monstrosity is even an acceptable idea. Let's keep WebAssembly lean and fast! Anything extra can (and should) be implemented by other technologies.

IshKebab 3mo ago
I disagree. We shouldn't just be copying Unix until the end of time.
- iqihs 3mo ago
  less copying and more keeping in the spirit of, as it has clearly shown it is a model that is built to last
  - IshKebab 3mo ago
    It clearly hasn't, if you've been paying any attention to security. The Unix security model is that all code that a user runs is 100% trusted. That's absurd in today's world.
  - Ericson2314 3mo ago
    That's like saying "the US Constitution has clearly shown it's a model that is built to last" Sometimes bad designs stick around due to pure inertia
    - tete 3mo ago
      Even if something lasts due to pure inertia it lasts. And something that lasts is pretty nice if you want a standard to last, or be implemented. The standard usually isn't the thing that you use to proof you can do something better, by being different. Because then everyone will have a harder time adapting it. People implement interfaces they dislike. Since this is related to Webassembly, Browsers, the Web. The web has a lot of historically baggage, that one might have to work around at times, sometimes more sometimes less. There are good bits and not so good bits and in the end a lot of the time more modern web applications (whether you think they are good or bad) as well as web browsers jump through hoops to do things. For many applications there would be better protocols. But it became the dominant standard, a standard that is actually being used a lot and that is why it has become a success story. It wasn't a hundred times better than everything else. It simply was something that people managed to implement successfully and something where they were willing to deal with shortcomings, because there are great benefits in implementing the same standard as everyone else. Don't know much about the US constitution, but it seems that it was largely good enough to make people work together that otherwise might have ended up fighting each other. That's what you'd get if everyone had a different idea about what a good constitution is. Maybe things are unclear, and maybe there are uproars because of things, but it doesn't even get to that if people don't agree on a standard or a constitution in first place. And while over the years I often imagined how great it would be if everyone just used that better standard that has been there for a long time and nobody uses and is completely forgotten, if it ever had any popularity, then everything would be so much better and greater and I wouldn't have to do that senseless thing I am doing now. But if that standard doesn't allow for people to agree with it by implementing it it's essentially worthless (outside of maybe "prior art" consideration). And like it or not we currently live in a world where designs persist due to pure inertia. But we know that obviously people are willing to implement these which means when a standard comes along that is similar to what already is there then having many people adapting it is realistic. Otherwise it's that super interesting university project that never makes it into anything in the real world.

ilaksh 3mo ago

Is there some Zig code demonstrating how to use all the changes in a Zig program that compiles to WASI 0.3.0?

jedisct1 3mo ago
There's https://github.com/ofalkenberg/zig-wasi-components https://github.com/ofalkenberg/zig-wasi-components

yoshuaw 3mo ago

Hey everyone, we just published the announcement post for WASI 0.3 on the Bytecode Alliance blog: https://bytecodealliance.org/articles/WASI-0.3 https://bytecodealliance.org/articles/WASI-0.3 The current link is just the release notes and covers only the interface-level changes. The announcement post goes into more detail on what's new in WASI 0.3, how it differs from WASI 0.2, and includes examples.

dang 3mo ago
Ok, I've swapped that link in at the top and put the submitted URL (https://github.com/WebAssembly/WASI/releases/tag/v0.3.0 https://github.com/WebAssembly/WASI/releases/tag/v0.3.0) in the toptext.
- yoshuaw 3mo ago
  Thank you!

_jsdw 3mo ago

This is funny timing to me, because just the other week I did a dive into WebAssembly and WASI 0.2 (https://jsdw.me/posts/wasm-components/ https://jsdw.me/posts/wasm-components/) and assumed that 0.3 would be a while yet as there was no obvious (to me) sign it would come for a while! Once the tooling is there and Rust has a wasi 0.3 target I'll give it more of a look at :)

mmastrac 3mo ago

I'd love it if WASI modules could introspect their own custom sections (potentially even more introspection than that), but I've never been able to figure out a good way to do this. Seems like a fairly useful feature for a few use cases.

WalterGR 3mo ago

Also see, from yesterday: https://news.ycombinator.com/item?id=48448083 https://news.ycombinator.com/item?id=48448083 “The Road to the WASM Component Model 1.0” (bytecodealliance.org) 95 points | by emschwartz | 99 comments

hmry 3mo ago

Does the stackfull async implementation use the stack-switching proposal? I was under the impression that it's not implemented in most runtimes (very difficult to retrofit into existing implementations), and only available on x86_64 Linux in wasmtime.

phickey 3mo ago
No, the stack switching proposal is not used. Stack switching is a set of core Wasm opcodes that permit a guest to change its own stack. Instead of using opcodes inside the Wasm, the stackful async mode of the component model’s ABI calls out into the component model implementation where it can manipulate the stacks with special host powers - JSPI is sufficient on web engines to express this, and wasmtime manages guest stacks in memory. When stack switching becomes available in all engines, it will be possible to implement this part of the component model in pure Wasm without host magic, e.g. web engines will be able to avoid the call out to JS to use JSPI.
- hmry 3mo ago
  Thank you, that's great to hear. I was worried it would be a long time before most runtimes could use WASIp3 if it required stack-switching.

syrusakbary 3mo ago

Congrats on the release to the WASI team. TL;DR: WASI 0.3.0 is the Component Model-based WASI proposal. It adds async/await-style capabilities such as actors and streams, and today is runnable in only one server-side Wasm runtime (it is not supported natively by browsers). Unfortunately it still breaks compatibility with the original WASI proposal and runtimes that supported it. If your goal is to compile existing, unmodified C/C++ programs and libraries to WebAssembly, WASIX may be a more practical option today ( https://wasix.org/ https://wasix.org/ ). Disclosure: I’m part of Wasmer, the company behind WASIX.

oexside 3mo ago

[flagged]