from Hacker News

WASI Support in Go

by spacey on 9/13/23, 4:27 PM with 49 comments

  • by dilyevsky on 9/13/23, 6:13 PM

    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...
  • by umvi on 9/13/23, 7:36 PM

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

  • by candiddevmike on 9/13/23, 7:57 PM

    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.

  • by kungfufrog on 9/13/23, 10:52 PM

    Can someone hit me with the value proposition of all this WASI stuff and WASM and ELI5? (I get the browser use-case)

    My understanding is as follows:

      WASM - a portable, platform-independent virtual machine for executing a "web assembly"
    
      WASI - an extension to the virtual machine that adds APIs for interacting with the system and breaks all the WASM sandboxing (presumably NOT platform-independent?)
    
    Is the point of this addition to Go that I can now target "WASM implementations that have WASI" with Go source code compiled to WASM?

    Why would someone want to do that? Just for edge functions in cloud workers?

  • by ramesh31 on 9/14/23, 12:36 AM

    Badass. The `GOOS=js` build had so many workarounds needed that it was barely worth it to port existing code, and wasm_exec.js always felt like a terrible hack. I'll be updating all of my stuff with this and pulling out the shims.