Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Talk about WASI #83

Open
rambip opened this issue Jul 18, 2021 · 4 comments
Open

Talk about WASI #83

rambip opened this issue Jul 18, 2021 · 4 comments

Comments

@rambip
Copy link

rambip commented Jul 18, 2021

I really apreciate you're referencing work !

I'm really interested in the most recent developements of webassembly, and I'm surprised you don't talk about WASI.

Wasi is a standard developed by bytealliance to be able to execute any wasm module outside the browser, by a runtime or by importing functions from another language.

There are some languages/compilers in the list that compile to webassembly, but doesn't implement this interface. As a result, you have to import some functions that are not at all standardized to run this assembly, so you must use javascript glue for I/O for example. They can't run outside the browser !!!

For example that is the case with emscripten: it implements non-standard functions, so you can't run it without javascript.

I think rust, c, cpp and go are the only languages that compile to this interface. You can look here

So it would be nice to present all the languages in a table, indicating if they compile to this standard or not.

@jedisct1
Copy link

Zig has always had excellent support for WASI, too.

@appcypher
Copy link
Owner

I haven't had the time to maintain this repo as I'm no longer actively following the WebAssembly scene.
I don't mind PRs that help with this.

@appcypher
Copy link
Owner

I haven't had the time to maintain this repo as I'm no longer actively following the WebAssembly scene.
I don't mind PRs that help with this.

This is no longer true. I will look into this

@jpaquim
Copy link
Contributor

jpaquim commented Sep 7, 2022

I see this and #61 maybe being solved using some kind of tags (or symbols + legend) for the implementations, describing whether they are:

  • An interpreter runtime compiled to mostly freestanding Wasm (optionally + supporting host code)
  • An interpreter runtime compiled to WASI-compatible Wasm
  • A compiler emitting freestanding Wasm (optionally + supporting host code)
  • A compiler emitting WASI-compatible Wasm
  • A hybrid setup where the interpreter/compiler runtime is compiled to Wasm and itself emits Wasm (like WAForth for instance)

I think that would make it easier to parse at a glance whether a language implementation is suitable for a particular use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants