Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASI Support in Go

go.dev

Post reply on HN
Print view View original

11–20 of 50 posts

Re: WASI Support in Go

#11

Post by dilyevsky »

candiddevmike wrote: post #6

I 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’s basically what jvm should have been but never delivered:

1. Could be an edge/iot play (tho not with standard go toolchain bc those binaries are huge and slow)

2. Trusted environment makes it interesting for all kinds of sbom-related usecases. Think weapons tech, space, etc

3. On the container side things are less clear to me but may offer better startup time, reduced footprint etc

4. Finally, for plugabble software it’s most interesting option personally. It’s basically 2.) but with focus on DX over security

Re: WASI Support in Go

#12

Post by dilyevsky »

viccuad wrote: post #10
dilyevsky wrote: post #2

I 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

Yeah there is an escape hatch via js package but it’s annoying

Re: WASI Support in Go

#13

Post by rockwotj »

dilyevsky wrote: post #2

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

FWIW we simulate exports by instead having `main` call an imported function that blocks until it's ready to return with the needed data.

So instead of:

`host -> call foo on guest -> return to host`

`host -> call guest main -> call foo on host -> host returns when ready -> guest calls foo when done`

FWIW the scheduler (so goroutines) don't work in go if you're not calling from an main, so anytime you call a custom export then try to use a goroutine you'll get panics.

10x size is about the blowup we see as well. It's also likely to be slower (some of the Tinygo authors said ~20% slowdown compared to tinygo) probably due to the simpler/smaller runtime and LLVM being better at optimizing.

Re: WASI Support in Go

#14

Post by rockwotj »

viccuad wrote: post #9
candiddevmike wrote: post #6

I 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…

How is the Universal Policy Engine different than Open Policy Agent?

Re: WASI Support in Go

#15

Post by jbrandhorst »

dilyevsky wrote: post #2

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

Exports are something we'd like to work on but it turns out it's pretty complicated to reconcile the Go runtime with the WebAssembly environment, especially when there's only a single thread. We'll get to exports as soon as we can but it may require Wasm threads to be stable first.

Re: WASI Support in Go

#16

Post by achille-roussel »

umvi wrote: post #4

I 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…

This is a good callout, although we probably won't be able to significantly improve the performance of Go compiled to WASM until WebAssembly evolves and introduces support for threads or stack switching so we can define goroutines based on those; right now the main reason Go compiled to WASM isn't in the ballpark of native perf is due to the stack switching emulation we have to do to get the cooperative scheduling of goroutines to work. We'll need WASM runtimes to offer more advanced primitives that we can rely on to implement those features of the Go language and produce much higher-quality code.

Re: WASI Support in Go

#17

Post by jbrandhorst »

alecthomas wrote: post #8
jsd1982 wrote: post #3

Earlier quoted context omitted.

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

There's no CGO involved when compiling to Wasm. The sometimes slow performance is due to the hoops the compiled code has to jump through to support the Go runtime and goroutine preemption on a single thread.

Re: WASI Support in Go

#18

Post by Thaxll »

viccuad wrote: post #9
candiddevmike wrote: post #6

I 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…

As if WASI does not need specific architecture and kernel features?

Re: WASI Support in Go

#19

Post by viccuad »

rockwotj wrote: post #14
viccuad wrote: post #9

Earlier quoted context omitted.

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…

How is the Universal Policy Engine different than Open Policy Agent?

Just gave a talk on Monday about it in containerdays.io, but the video is not in youtube yet!

In a nutshell, with Kubewarden we strive to build the universal policy engine by:

- Provide all personas (policy consumer, policy developer, policy distributor, engine admin, engine developer/integrator, etc) with current and future industry-standard workflows, not only a subset of personas, nor more than needed knowledge for those personas. It's a bold statement, and if it would be universal it should indeed cater to everyone.

- This is achieved with policies as code, which are Wasm modules: Wasm policies allows us to support Rego DSL (OPA/Gatekeeper), YAML, SDKs for Wasm-compiled languages, and now an experimental Kyverno DSL policy by compiling it to WASM with WASI. Great for using your language and tools of preference.

- Wasm modules have first class support In OCI registries, just like container images: Use same tools that you know as artifact distributor: SBOMs, signing and verifying with cosign, airgap, slsa.dev, etc.

- Policies can be evaluated out-of-cluster: great for CI/CD, dev loop, integration tests, etc.

- Modular architecture informed by using Wasm policies: OCI registry, policy-server, k8s controller, out-of-cluster cli (kwctl), etc. This also helps in adopting future industry-standard workflows.

- Usual features of a Policy engine (mutating, context-aware, recurring scanner of already in-cluster resources, etc). Plus ample room for new features thanks to the architecture. E.g: possibility to run the policy-server directly in the k8s apiserver (one colleague already presented that in Kubecon), possibility to evaluate out-of-cluster policies outside of clusters like OPA just by running the policy-server standalone, more DSLs compiled to Wasm, more languages, etc.

- Vendor neutral, CNCF project, open source, developed in the open.

Re: WASI Support in Go

#20

Post by carbotaniuman »

Thaxll wrote: post #18
viccuad wrote: post #9

Earlier quoted context omitted.

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…

As if WASI does not need specific architecture and kernel features?

WASI runners are just an application. I guess you need your kernel to run prograns and have syscalls, but that is a low bar.
Post reply on HN