WASI Support in Go
go.dev
WASI Support in Go
1–10 of 50 posts
Re: WASI Support in Go
#2I wish they added some way of exporting wasm funcs as well so that they could be called from host. Tinygo wasm target supports both "exports" and "imports". The other thing that is worse compared to tinygo is the generated binary size seems to be about 10x larger. From my brief look at the transpiled .wat printout a lot of included funcs aren't being called anywhere...
Re: WASI Support in Go
#3I wish they added some way of exporting wasm funcs as well so that they could be called from host. Tinygo wasm target supports both "exports" and "imports". The other thing that is worse compared to tinygo is the generated binary size seems to be about 10x larger. From my brief look at the transpiled .wat printout a lot of included funcs aren't being called anywhere...
The go-compiled wasm is also extremely slow compared to tinygo's wasm. Doing simple things like `fmt.Printf()` degraded performance significantly.
Re: WASI Support in Go
#4I feel like we need better WASM performance in go before we get WASI. In my experience go wasm performance is pretty bad, usually significantly worse than vanilla JS.
Rust (or really anything LLVM backed) is still probably the best WASM language in terms of performance and support, but .NET (don't forget to turn on AOT) is starting to get really good too (except for the fact that .NET compiler barfs out a bazillion files that the browser needs vs. 1 self contained .js or .wasm file which sucks if you are trying to build a self contained library like OpenCV.js)
Re: WASI Support in Go
#5I feel like we need better WASM performance in go before we get WASI. In my experience go wasm performance is pretty bad, usually significantly worse than vanilla JS. Rust (or really anything LLVM backed) is still probably the best WASM language in terms of performance and support, but .NET (don't forget to turn on AOT) is starting to get really good too (except for the fact that .NET compiler barfs out a bazillion f…
> usually significantly worse than vanilla JS
Can to elaborate?
This is can be true if you're interacting with browser API's such as the DOM frequently, because there's an overhead.
But I've seen several projects where (non-GC) WASM has improved performance significantly for specific tasks. You won't get native performance obviously.
Re: WASI Support in Go
#6I still don't understand the benefit of running a Go app on a cloud provider using this. Anyone want to help me?
Is it an edge play for using something like Cloudflare Workers?
Is it cheaper vs standard serverless/container deployments? Go apps can already scale to 0 for these use cases.
Re: WASI Support in Go
#7I still don't understand the benefit of running a Go app on a cloud provider using this. Anyone want to help me? Is it an edge play for using something like Cloudflare Workers? Is it cheaper vs standard serverless/container deployments? Go apps can already scale to 0 for these use cases.
I believe the primary benefit is the sandboxing, but I imagine there are secondary benefits such as that the host platform can be any CPU architecture or OS.
Re: WASI Support in Go
#8I wish they added some way of exporting wasm funcs as well so that they could be called from host. Tinygo wasm target supports both "exports" and "imports". The other thing that is worse compared to tinygo is the generated binary size seems to be about 10x larger. From my brief look at the transpiled .wat printout a lot of included funcs aren't being called anywhere...
The go-compiled wasm is also extremely slow compared to tinygo's wasm. Doing simple things like `fmt.Printf()` degraded performance significantly.
I wonder if fmt.Printf() in particular is slow due to the CGo transition? Assuming there even is a CGo transition when compiled to WASM...
Re: WASI Support in Go
#9I still don't understand the benefit of running a Go app on a cloud provider using this. Anyone want to help me? Is it an edge play for using something like Cloudflare Workers? Is it cheaper vs standard serverless/container deployments? Go apps can already scale to 0 for these use cases.
It consolidates Go compiled to WASI as an alternative of doing containers.
Linux containers don't "Run anywhere." as docker.io says. You need a specific architecture and kernel features, which is not obvious from afar.
There's also other benefits. Example: the team I work on compiled Kyverno, a CNCF K8s policy engine written in Go, to a WASI target. We are building Kubewarden, a CNCF policy engine where policies are Wasm binaries shipped in OCI registries. We strive to build "a Universal Policy Engine". Now, we have an experimental Kubewarden policy `kyverno-dsl-policy` that allows you to reuse Kyverno DSL with us. We also provide WaPC as a target, more performant and secure, hence normal SDKs for Go, Rust, C#, swift, typescript... In addition to supporting Rego, again compiled to Wasm.
IMHO you only benefit from the real sandboxing from WaPC, as WASI's posix-like interface allows you to attack the host.
The next step for the official Go compiler is to export the function symbols, to allow for WaPC.
Re: WASI Support in Go
#10I wish they added some way of exporting wasm funcs as well so that they could be called from host. Tinygo wasm target supports both "exports" and "imports". The other thing that is worse compared to tinygo is the generated binary size seems to be about 10x larger. From my brief look at the transpiled .wat printout a lot of included funcs aren't being called anywhere...
I'm also waiting for that :)
See https://github.com/golang/go/issues/42372