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

21–30 of 50 posts

Re: WASI Support in Go

#21

Post by alecthomas »

jbrandhorst wrote: post #17
alecthomas wrote: post #8

Earlier quoted context omitted.

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.

I understand there's no CGo specifically, but I'm wondering if the Go runtime when running under WASM still has to manage switching out the goroutine stacks for "WASM stacks" when it's calling out through the WASM VM.

Edit edit: from this comment it sounds like it is, as you say, just the general overhead of managing goroutine stacks. I wonder if TinyGo is more performant.

[1] https://news.ycombinator.com/item?id=37501552

Re: WASI Support in Go

#22

Post by Thaxll »

carbotaniuman wrote: post #20
Thaxll wrote: post #18

Earlier quoted context omitted.

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.

Docker needs the 3.10 kernel which is 10 years old.

Re: WASI Support in Go

#23

Post by kungfufrog »

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?

Re: WASI Support in Go

#24

Post by mbertschler »

Thaxll wrote: post #22
carbotaniuman wrote: post #20

Earlier quoted context omitted.

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

Docker needs the 3.10 kernel which is 10 years old.

But it needs Linux, while wasm runtimes are available for all OSes natively

Re: WASI Support in Go

#25

Post by favflam »

kungfufrog wrote: post #23

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…

You can theoretically run untrusted code from customers in a secure sandbox. This is a simpler proposition that letting customers run vms.

Re: WASI Support in Go

#26

Post by skybrian »

kungfufrog wrote: post #23

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…

As I understand it, WASI doesn't break all security, or at least not by default. Here's a document about capabilities-based design:

https://github.com/bytecodealliance/wasmtime/blob/main/docs/...

Re: WASI Support in Go

#27

Post by noveltyaccount »

kungfufrog wrote: post #23

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…

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

Re: WASI Support in Go

#28

Post by Patrickmi »

alecthomas wrote: post #21
jbrandhorst wrote: post #17

Earlier quoted context omitted.

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.

I understand there's no CGo specifically, but I'm wondering if the Go runtime when running under WASM still has to manage switching out the goroutine stacks for "WASM stacks" when it's calling out through the WASM VM. Edit edit: from this comment it sounds like it is, as you say, just the general overhead of managing goroutine stacks. I wonder if TinyGo is more performant. [1] https://news.ycombinator.com/item?id=375…

Tinygo runtime don’t have g or m threads that’s why it’s Cgo is zero cost

Re: WASI Support in Go

#29

Post by est31 »

Thaxll wrote: post #22
carbotaniuman wrote: post #20

Earlier quoted context omitted.

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

Docker needs the 3.10 kernel which is 10 years old.

It also needs root access, and 3.10 is only the lowest supported kernel. Not a docker expert but I could bet that they only support a subset of features there.

What I do know is that docker images are specific to the host architecture, supporting either one architecture, or a blessed list. wasm binaries on the other hand aren't. wasm can theoretically also run on bare-metal embedded scenarios without an OS entirely.

Re: WASI Support in Go

#30

Post by eddythompson80 »

noveltyaccount wrote: post #27
kungfufrog wrote: post #23

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…

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.
Post reply on HN