WASI: WebAssembly System Interface | Hacker News Reader

WASI: WebAssembly System Interface

github.com

123 pointsteleforce76 comments

There is the WASI SDK if you want to target WASI from C/C++:

It comes with a libc implemented in WASM.

A common option for that purpose is Zig. WASI is just one of the many targets it can compile C code to, out of the box: `zig cc -target wasm32-wasi`. No need to install yet another LLVM copy.

Zig produces more optimized code, because it optimizes the libc like the rest of the application. So you can enable additional WebAssembly features according to the target runtime, for example `zig cc -target wasm32-wasi -mcpu=baseline+bulk_memory+simd128`.

And you get automatic caching for free.

That's cool and all, but how do I get it to use a linker that understands those options I give to `wasm-ld` (`--allow-undefined`, `--export-all`, `--no-entry`)? As it is, I'm getting “error: unsupported linker arg: --allow-undefined” when I pass that with `-Wl,`.

-Wl,--import-symbols -Wl,--export-all-symbols -Wl,--entry= (or rather -mexec-model=reactor).

WASI is kind of in a hard place now

There is the version 1 which is not allowed to continue for political reasons (and that’s the one that everyone is implementing because it actually works)

and there is version 2 that redoes everything from 0.

Also there is wasix from an entirely different team that builds on top of version 1

> version 1

You mean preview 1? It was never meant to be a finished spec that would remain supported long-term; it was a preview for early adopters and people working in the space to experiment with.

> allowed to continue for political reasons

Uh... what?

There is no development on the preview 1; and the new development went in new direction so the preview1 or snapshot1 or whatever is the name is stuck

Luckily the wasix is more pragmatic and continues where that left off

Genuinely curious: what are you working on that makes POSIX compatibility important, but also warrants using Wasm instead of just building native executables?

I ask because I'm personally much more excited about the future of WASI, because it brings so much to the table that it feels like it's actually worth the effort of building something new — I see it as a game changer. I.e. what you appear to view as an unnecessary diversion, I see as the whole point. So I'd love to understand more about your perspective and use case.

And there are runtimes and services implementing their own APIs, and there's emscripten which is how most people actually use WebAssembly today. But if you're not porting existing software and only care about the web, these APIs are not very relevant. Oh, and WebAssembly also looks very different if you are using it for smart contracts.

This is due to the fact that WebAssembly was not specified with an API to actually use it. But it's okay. CPUs don't ship with an operating system either. It doesn't make them useless, nor prevents multiple operating systems from existing.

I’m happy to see more excitement on the Wasm area.

For the cases where you may need full POSIX compatibility for sockets, threads, signals or even fork or longjmp/setjmp, I’d recommend using WASIX [1] (also referenced in other comments here) since it has implemented all those system calls missing from WASI.

[1]: https://wasix.org

Relevant but not mentioned: syrusakbary is the CEO of Wasmer, the company behind WASIX. I'm personally excited by WASIX (WASI has stagnated too long), but if you recommend something you have a part in, I think you should mention it.

That’s me! Hopefully the extra info provided would be useful for some :)

Runtimes didn't wait for WASIX to start adding missing system calls to WASI.

But WASIX brings a central place to document all this.

And I don't think WASIX is fundamentally incompatible with the future WASI. The different ABIs doesn't make this straightforward, but WASIX could be available as WASI extension like others.

The guy that tried to trademark the Webassembly name btw and it's constantly trying to hijack the community with halfbaked solutions instead of pushing forward the standard, cause Wasmer had beef in the past with bytecode alliance peeps.

WASI and WASM move slow for a good reason, This is how proper science and engineering works. The "go fast and break things" mentality of silicon valley startups has mainly filled the industry with low quality software.

I imagine Wasmer must be in a bit of a difficult place right now. My understanding is that they are VC-backed (YC?), which means they're essentially trying to figure out how to make a huge amount of money off an open standard or something adjacent to it. But then, they would have known this from the very start, so I'm not sure what they expected, or why a VC firm would even look at them as a promising prospect.

Maybe they hoped to be like Docker, where the value-add was cohesive higher-level tooling on top of all the lower-level bits. If that's the case, then WASI would be an existential threat in that it (and the tooling people are building around it) commoditizes what would otherwise be Wasmer's special sauce. I'm speculating wildly, of course, but it would at least be consistent with Wasmer's/Sirius's apparent vendetta against WASI and the people working on it.

I hope Wasmer eventually finds a way to add value that doesn't rely on constant gaslighting and white-anting the standards process.

Hey Jeff,

My response is focused here to be as productive as possible, and intentionally doesn't enter your other comments about Wasmer or my persona as, while incredibly accurate, I want to make sure we keep conversation properly railed.

We recently presented Wasmer Edge [1], for which developers, enterprises and VC firms are incredibly excited for it as it brings a more scalable approach for both Cloud and Edge computing. Please give it a try and let us know if you have any questions!

https://wasmer.io/products/edge

*incredibly inaccurate (oh, subconscious!)

Hi laerus,

I wonder why the need to post hateful/flamewar comments in all the Hacker News posts where Wasmer is mentioned [1] [2] [3].

In my last comment on a previous thread [1], I asked a direct question to see if you are related at all to the BA, without success. I'd love if you can bring some light on this, and I'd appreciate if you can do so without trying to start a flamewar.

[1] https://news.ycombinator.com/item?id=36509911 (on Zellij Wasm plugins)

[2] https://news.ycombinator.com/item?id=36128284 (on WASIX launch)

[3] https://news.ycombinator.com/item?id=33835683 (on WAI bindings)

hey, I am not affiliated with BA at all. I just don't like you and what you represent. The filth of silicon valley startups that try to make money off of the hard work and love some people put on their projects. Open source peeps do not need your pathetic public apologies which is obvious just another marketing strategy since you relized you f'ed up.

I've never seen a worse-described project than WASI.

"Component model interfaces always support link-time interposition."

Like WTF does this mean? The repo tells me nothing and I've still yet to see a clear write-up about what WASI is. I click on "docs" folder and there's one file. https://github.com/WebAssembly/WASI/blob/main/docs/WitInWasi.... WTF is wit? This should be in a CONTRIBUTORS.md not in the docs folder. I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs. Wikipedia tells me WASI is a POSIX-like interface but with POSIX I know exactly where to look up the functions. Where's a single well-written WASI spec?

I'll be honest - this whole project feels like candy for architecture astronauts and goes against the spirit of WebAssembly. Looks at how well-written WebAssembly's goals are: https://webassembly.org/docs/high-level-goals/. Their spec is easy to find and easy to read. This is what I want from WASM. Whatever WASI is doing, I don't like it. And neither does AssemblyScript team apparently: https://www.assemblyscript.org/standards-objections.html.

They mean that an environment can always provide a fake version of a function to a webassembly program. They’re defining an API but there’s no requirement to implement it.

It seems like a rather weak specification where nothing is required to work? But at least it defines an interface. You might compare it to Go or Java interface types.

You're referring to yet another part of WASI, which is indeed about defining domain-specific sets of APIs.

No specific set is required to be implemented. So an application can work somewhere, and not load elsewhere.

But the idea is that similar environments will hopefully implement similar APIs, and there's a mechanism to encourage that ("worlds").

Not only interfaces are defined. As an illustration, the WASI Crypto proposal includes a lot of details on how individual functions must behave, because in this context, it's critical to avoid inconsistencies between implementations.

Good to hear. I was basing what I wrote on the previous sentence:

> This can be used to adapt or attenuate the functionality of a WASI API without changing the code using it.

It sounds like someone (who?) can use middleware to override an API to do whatever they like, even though there are specifications elsewhere about what they must do.

In the context of virtualization, would this allow things like running one virtual machine inside another? Sandboxes all the way down?

It's more like regular shared libraries.

You can replace a library with a different one that loads the original library, defines the same symbols, and forwards the function calls.

That's how debugging/protocol inspection tools like 6Jack work, and it's pretty convenient.

It could be done with static libraries, but that would require renaming all the symbols of the upstream library.

> "Component model interfaces always support link-time interposition." > > Like WTF does this mean? The repo tells me nothing

Directly above the sentence you quoted:

"Interposition in the context of WASI interfaces is the ability for a Webassembly instance to implement a given WASI interface, and for a consumer WebAssembly instance to be able to use this implementation transparently. This can be used to adapt or attenuate the functionality of a WASI API without changing the code using it."

> and I've still yet to see a clear write-up about what WASI is.

In the same document: [0]

> WTF is wit?

The first link in that document ("Starting in Preview2, WASI APIs are defined using the Wit IDL.") is [1].

> I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs.

The README for the legacy directory [2] clearly explains what they are.

> Where's a single well-written WASI spec?

"Development of each API happens in its own repo, which you can access from the proposals list." [3]

> Whatever WASI is doing, I don't like it.

Clearly not - you've gone out of your way to ignore all of the documentation that answer your questions.

> And neither does AssemblyScript team apparently

The AssemblyScript team have a bone to pick with WASI based on their misunderstanding of what WASI is for (it is not intended for use on the web) and WASI's disinterest in supporting UTF-16 strings. You can see for yourself in [4].

[0]: https://github.com/WebAssembly/WASI/tree/main#wasi-high-leve...

[1]: https://github.com/WebAssembly/component-model/blob/main/des...

[2]: https://github.com/WebAssembly/WASI/blob/main/legacy/README....

[3]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md

[4]: https://github.com/WebAssembly/WASI/issues/401

None of this is excusable. Tell me what your project does in clear English.

"WASI is a standard for 50 functions you can call to do systems-level things from your WASM code. Here they are."

Done.

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. I don't want to see your copy-pasta goals from WASM (which aren't clear for WASI). You're an API. Show me the API.

https://wasix.org/docs may be what you are looking for.

The WASI section documents WASI as it is implemented today.

But since then, WASI pivoted and has become an umbrella for multiple projects. This is not just an API any more, and at the moment, the documentation on the WASI site and repositories is for WASI developers, not for developers using WASI. So if you didn't follow the whole thing, it is indeed be very hard to understand. The stack is complicated. But the ultimate goal of the project is to actually make it easier for developers to use wasm, without having to worry about all these details.

It's essentially about adding dynamic linking to wasm. The dynamic libraries embed the function prototypes, so that calling functions with the wrong type will cause a link error. That requires the definitions of every type of function, and WIT, WAI and WITX are domain-specific languages to do that.

Right now, WebAssembly is limited to static linking. It works very well, even across languages, but types aren't automatically checked. Actually, they are, but only using the primitive types available in WebAssembly. Here, the goal is to support something very close to the Rust type system.

The proposal also allows restricting every library to their own memory region. So, a buggy or malicious library can only mess with its own data, not with the rest of the application.

A million times better. Looks like this comes from the Wasmer team.

Interesting. This seems almost like an object-oriented system where the objects can be large libraries written in different languages.

Do libraries have a lifecycle? Can you instantiate multiple instances of them?

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

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

To put it bluntly, they are redoing SOM, CORBA, COM and .NET component model, and calling it a novelty.

Yes I agree that this is novel and a new frontier in software.

It's basically a POSIX interface for WASM.

I also agree with the AssemblyScript people. WASI is driven by people saying "I want to be able to compile existing Linux software to WASM and run it on a server!" and to do that they have pretty much just copied POSIX.

Great for running old software, but it seems very short sighted to me to tie WebAssembly to 70s UNIX design.

It'll probably be popular because people apparently love never fixing things...

Reply on news.ycombinator.com