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.
WASI Support in Go
31–40 of 50 posts
Re: WASI Support in Go
#32I 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.
>Can to elaborate?
The overhead of a runtime can easily make WASM code run slower than native JS functions. This only applies to GC languages like Go which require that.
>But I've seen several projects where (non-GC) WASM has improved performance significantly for specific tasks. You won't get native performance obviously.
You absolutely can if you're writing the raw WASM or compiling from C.
Re: WASI Support in Go
#33Earlier quoted context omitted.
It enables a future world where CPU architecture, OS, and runtime don't matter. Code from any language can run on any hardware and interop with any other code. Cloud hosts can buy whatever hardware is most economical and your code will work there. Just like Docker eliminated a lot of tedious dependency management for deployment, this eliminates another chain of dependencies, but CPU, language runtime, and operating s…
Sun Microsystems would like a word with you.
Re: WASI Support in Go
#34Can 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…
Think “JVM, but better this time”. Better isolation, and more language-agnostic. So, Kubernetes with WASM application servers as an alternative to container runtimes. All the old Java ideas, but hopefully much better. It being originally made for the web has the advantage of it being built with security in mind from the get-go. The JVM was always unsuited for running untrusted code, among other failings.
Re: WASI Support in Go
#35I 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.
Just curious what state is it (thread support) in now? I saw wasmtime already supporting some pthread style threads so assumed proposal has already been accepted but it’s super hard to actually figure out what state anything is in with wasm…
Re: WASI Support in Go
#36I 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 exp…
The only time I tried wasm in Go, the wasm compiled by the native Go was so slow that the equivalent Javascript was faster. Tinygo produced decent performance however.
Re: WASI Support in Go
#37Can 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…
Think “JVM, but better this time”. Better isolation, and more language-agnostic. So, Kubernetes with WASM application servers as an alternative to container runtimes. All the old Java ideas, but hopefully much better. It being originally made for the web has the advantage of it being built with security in mind from the get-go. The JVM was always unsuited for running untrusted code, among other failings.
Wasm is anything but 'secure'.
You should go watch any of the numerous blackhat presentations on wasm or just talk to some of the security researchers out there. You can do attacks that most people haven't been able to do for 20+ years.
Wasm has horrible security.
Re: WASI Support in Go
#38Earlier quoted context omitted.
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.
Just curious what state is it (thread support) in now? I saw wasmtime already supporting some pthread style threads so assumed proposal has already been accepted but it’s super hard to actually figure out what state anything is in with wasm…
I would like to second that last statement. If anyone knows a good place to keep up with it all I'd appreciate it
Re: WASI Support in Go
#39Earlier quoted context omitted.
Just curious what state is it (thread support) in now? I saw wasmtime already supporting some pthread style threads so assumed proposal has already been accepted but it’s super hard to actually figure out what state anything is in with wasm…
I would like to second that last statement. If anyone knows a good place to keep up with it all I'd appreciate it
Threads are Phase 3
https://github.com/WebAssembly/proposals
You can also check out:
https://webassembly.org/roadmap/
And for Go, the proposal project on Github has many interesting conversations from the devs.
And as a reminder to anyone interested in using Go WASM, it’s experimental and does not come with the same compatibility promise as Go itself:
Re: WASI Support in Go
#40I 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…
Would the emulation penalty still occur if Go routines aren't used at all? I have many small domain-specific libraries that I am planning to port to wasm. These libraries only allocate dynamic memory and differ anonymous functions.