-
Notifications
You must be signed in to change notification settings - Fork 199
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
Comments
Zig has always had excellent support for WASI, too. |
I haven't had the time to maintain this repo as I'm no longer actively following the WebAssembly scene. |
This is no longer true. I will look into this |
I see this and #61 maybe being solved using some kind of tags (or symbols + legend) for the implementations, describing whether they are:
I think that would make it easier to parse at a glance whether a language implementation is suitable for a particular use case. |
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.
The text was updated successfully, but these errors were encountered: