Item — HN Reader

> Tell me what your project does in clear English.

Okay.

"Define a set of portable, modular, runtime-independent, and WebAssembly-native APIs which can be used by WebAssembly code to interact with the outside world. These APIs preserve the essential sandboxed nature of WebAssembly through a Capability-based API design."

That's the first goal.

> I don't care about wit/witx. I don't care the repo being in transition. I don't want to read about interposition or components or capabilities.

Everything you've just mentioned is relevant to people implementing the spec, given its wide scope and nature. It is not reducible complexity.

It is not a drop-in replacement for POSIX (i.e. it is not "a standard for 50 functions"); it goes beyond that, and aims to provide a secure and modular way to interact with the system where capabilities can be delegated or reduced.

1 comments

I implemented my first real-world project in WASM for OSS Summit, and everything you said about WASI echoes my real-world experience. It's not a set of functions to call. It's a terrific bundle of constraints (enabling constraints) on how to interact with the world outside of WASM, that embracing will force you to make your problem smaller until it's well-defined and testable, unit-ized even.

You're not building the old monolith the same old way in WASM, at least not if WASI is the main tool in the toolbox. And you're also probably not building the whole thing in WASM, (whatever it is that you had as original goal to build as an enterprise.) I think we'll have legacy code that needs to integrate with WASM for a time, and the time might be forever.

As a Rubyist, from this perspective I have been studying WASM and I have to admit I was really disappointed when I first began to understand the limitations we have in the current crop of tools – I now firmly believe the next generation of WASM tools will do it better.

Sweeping enhancements that are going to change it all again. Dynamic loading will hopefully bring us the capability for Ruby gems with C extensions to join the vfs assembly. (But now, as an end user and not a deep systems implementor, this is the part of the conversation where I begin to lose the plot, and going out of my depth...)