Mozilla, Fastly and others have started work on a new standard interface for WASM to interact with system calls, they're calling it _WASI_, the _WebAssembly System Interface_.
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
I think we should consider supporting this in the Go WASM architecture, possibly under a new OS (GOOS=WASI).
This issue should track the development of such an effort.
Mozilla have invited interested parties to join the #wasi channel on the Mozilla IRC server (https://wiki.mozilla.org/IRC).
@neelance @agnivade
I'm already looking into this. Yes, this is likely to become the GOOS/GOARCH wasi/wasm
. My current long term plan is to also make js/wasm
partially use WASI as soon as a feature can be expressed with WASI without losing any functionality.
https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-api.md this looks like a good list to reference.
My WIP for WASI can be found here: https://github.com/neelance/go/tree/wasi
There is no GOOS=wasi
yet, use GOARCH=wasm
+ GOOS=js
to target WASI. The fork is thus not compatible with wasm_exec.
This is a very important thing.
Wasi can be a new containerisation approach but running on mobiles, desktops, IOT and servers. It solves is able to solve a fundamental problem of trusting code from someone else with the host deciding what file / network IO the third party code has access to.
Sort of like how android will prompt you when an app wants to access your contacts or file system.
Wasmer git repo has it working for golang, python using a rust wasm / wasi engine currently btw. It's fast too.
https://github.com/wasmerio/go-ext-wasm
It seems that there is not IDL / RPC standard yet for WASI though. I looked but could not find. If anyone knows would be great.
@gedw99 you should probably ask on the WASI repo instead. Not sure if https://github.com/WebAssembly/WASI/issues/49 is what you're looking for. Either way WASI is still in active development so it is normal that certain things are lacking.
It's great to see there's some interest here! How is the progress? I see a recent commit from Dec 26, 2019 and one before that on Mar 29, 2019 in the fork of @neelance.
I recently stumbled on https://webassembly.sh, which drops you into a shell where you can execute WebAssembly binaries that were packaged with the WebAssembly Package Manager (wapm
, by the Wasmer guys) and target WASI: https://wapm.io/interface/wasi
There are small command line programs like cowsay
and lolcat
, but some people seem to try to experiment with bigger things as well (TiDB, but didn't try it out).
So naturally, I'd like to experiment with this new tech and create a WASI-targeting WASM file with Go, upload it to wapm and try it out on webassembly.sh :)
@philippgille I've updated my fork and just successfully ran a Go program on webassembly.sh. Try hello-go
.
@neelance can we get a status update on WASI support? What's still missing? Do you need help with anything?
Very excited to get this working - combining the portability of WASI with the strength of Go will open up lots of opportunities. :smiley:
Any update on this?
A reminder that this is open source and there are no ETAs, especially when it comes to external contributions such as Richard's. He hasn't posted any update in this thread since March, so that's the latest update. If you want to be notified of updates, subscribe to the thread. Aside from that, the best way to speed up progress is to check out his work, figure out how it works, and try to improve it.
Open source doesn't mean there is no ETA.
@inliquid That is true but I hope that the meaning is reasonably clear. Please be charitable in your understanding of what other people write. Thanks.
See https://github.com/golang/go/issues/38248 for what I was working on. No ETA though. Depends on how much time I get to spend on contributing to the Go project.
That is true but I hope that the meaning is reasonably clear. Please be charitable in your understanding of what other people write. Thanks.
Meaning is clear and it's not correct. At least in a form when someone replies to very reasonable question "this is open source". Open source doesn't mean work is not paid or not compensated in other ways. In most cases it's just one of the business models. So no one should feel like asking for ETA or just a progress is something wrong.
@inliquid the ETA is whenever @neelance feels like it.
Open source doesn't mean work is not paid or not compensated in other ways.
@inliquid Just to be clear: I am not getting compensated for my work on WebAssembly/WASI in any way. I am not even using it at my day job. I just work on it because I believe it should exist.
@icholy The phrasing of your comment is ambiguous, at least to me.
@neelance sorry, I meant that you have no obligation to provide a timeline for your free (and awesome) work.
Just to be clear: I am not getting compensated for my work on WebAssembly/WASI in any way. I am not even using it at my day job. I just work on it because I believe it should exist.
Sad that hear that you don't have any compensation of your work for WebAssembly in Go. But good to know that Google invests exactly nothing in this project.
Let's please remain on topic. Yes, we all wish Go had more features and less bugs. There are literally thousands of issues open, and priorities are different depending on who is asked.
I'll hide the last comment and any future ones that just continue on the topic of ETAs, so the thread can just go back to development.
Is it possible to run wasm code inside of golang? Is this the other side of the same coin with WASI?
@timcash this ticket is about compiling Go apps into WASI-compatible wasm binaries.
But it's also possible to run WASM inside of your Go app, for example you can use Wasmer or our Wasm3 engine (via https://github.com/matiasinsaurralde/go-wasm3 bindings).
There's also a WAVM fork with Go bindings (that work just fine with recent versions of WAVM).
There's also Wasmtime bindings via CGO.
Most helpful comment
I'm already looking into this. Yes, this is likely to become the GOOS/GOARCH
wasi/wasm
. My current long term plan is to also makejs/wasm
partially use WASI as soon as a feature can be expressed with WASI without losing any functionality.