Remix.run Logo
WASI 0.3.0 Released(github.com)
114 points by mavdol04 2 hours ago | 29 comments
garganzol 36 minutes ago | parent | next [-]

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 3 minutes ago | parent [-]

I disagree. We shouldn't just be copying Unix until the end of time.

b33j0r an hour ago | parent | prev | next [-]

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.

hectaman 15 minutes ago | parent | next [-]

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: 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-..., https://wasmcloud.com/community/, 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

- "The Path to Components": https://www.youtube.com/watch?v=phodPLY8zNE

- "Towards a Component Model 1.0" (Wasm I/O 2026): 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?

airstrike 23 minutes ago | parent | prev [-]

It's version 0.3...

ilaksh 7 minutes ago | parent | prev | next [-]

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

simonw an hour ago | parent | prev | next [-]

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

lifty an hour ago | parent | prev | next [-]

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.

utopiah 28 minutes ago | parent | next [-]

I tinkered with 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

airstrike 23 minutes ago | parent | prev | next [-]

Extending my Rust binary with a marketplace of WASM-based extensions like VSCode

jedisct1 15 minutes ago | parent | prev | next [-]

The best usage example of WASI I know of is the Zig compiler: https://ziglang.org/news/goodbye-cpp/

tdhz77 37 minutes ago | parent | prev | next [-]

Edge rural farm systems

OtomotO 43 minutes ago | parent | prev [-]

extending software with a plugin system

shevy-java an hour ago | parent | prev [-]

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.

modulovalue an hour ago | parent | next [-]

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 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 15 minutes ago | parent [-]

> 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")?

CGamesPlay an hour ago | parent | prev | next [-]

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 38 minutes ago | parent [-]

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

kettlecorn an hour ago | parent | prev | next [-]

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.

Dwedit 18 minutes ago | parent | prev | next [-]

WebAssembly doesn't beat JavaScript in performance, and that is embarrassing.

kettlecorn 10 minutes ago | parent [-]

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

callahad 42 minutes ago | parent | prev | next [-]

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.

__s an hour ago | parent | prev | next [-]

It has, but its usually just an optimization, so goes unnoticed

grufkork an hour ago | parent | prev | next [-]

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.

OtomotO an hour ago | parent | prev | next [-]

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.

lioeters an hour ago | parent | prev | next [-]

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.

artemonster an hour ago | parent | prev [-]

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 36 minutes ago | parent | next [-]

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 34 minutes ago | parent | prev [-]

Why can’t you?