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

41–50 of 50 posts

Re: WASI Support in Go

#41

Post by lifthrasiir »

bigassdbload wrote: post #37
tormeh wrote: post #34

Earlier quoted context omitted.

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.

> You can do attacks that most people haven't been able to do for 20+ years.

This is a bad and roundabout way to say that vulnerabilities in WebAssembly modules may still cause a corruption in their linear memory. Which is absolutely true, but those attacks still matter today (not everyone turns ASLR on) and similar defences also apply. In the future multiple memories [1] should make it much easier to guard against remaining issues. WebAssembly is a lucrative target only because it is so widespread and relatively young, not because it has horrible security (you don't know how the actually horrible security looks like).

[1] https://github.com/WebAssembly/multi-memory/blob/main/propos...

Re: WASI Support in Go

#42

Post by dilyevsky »

cplli wrote: post #39
beanjuiceII wrote: post #38

Earlier quoted context omitted.

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: https://github.com/golang/go/wiki/WebAssembly

Yes it's been in phase 3 for what like 2-3 years at this point (judging by when it landed in browsers)? No eta and no next steps. The tp says they are waiting until "it's stable" so I'm assuming phase 4. It qualifies browser support and "at least one toolchain" criteria[0] (zig) and seems like all the other conditions too except maybe "CG consensus" whatever that means, so for all I know it could take anywhere between tomorrow and in a few years from now...

[0] https://github.com/WebAssembly/meetings/blob/main/process/ph...

Re: WASI Support in Go

#43

Post by DanielHB »

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…

In my experience WASM performance is not that much better than JS in most cases, not so much because WASM is lacking, but because most JS runtimes performance is really, really good for a dynamic language.

When I measured C compiled with clang -O3 vs JS performance the only noteworthy speedup were on math-heavy tasks and even there only for integer-heavy math (floating point math was better than JS, but not by much). In a few cases the performance was worse. Notably recursive algorithms were _much_ better in WASM though even with algorithms that can't have tail-call optimisation (I guess function invocation has a lot of overhead in JS compared to C)

I think people over-value WASM speed. With regards to performance I imagine that the biggest gains compared to JS would be from not using garbage collection language. GC overhead, especially JS GC (compared to golang GC) can be painful in very large applications, especially in things were timings matter like 3d rendering. But GC can be optimised for in JS by avoiding allocations in the critical paths of the app

Re: WASI Support in Go

#44

Post by fathyb »

dilyevsky wrote: post #35
jbrandhorst wrote: post #15

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

Don't know about the server side, but I've been using threads on the browser for ~2 months, I didn't hit any bug specific to it yet. I use it both with Rust (wasmbindgen with async/await) and C (Emscripten with pthread support). HTTPS with some headers is required for `SharedArrayBuffer`.

I still build a single-threaded binary for Firefox, and fallback to it if `SharedArrayBuffer` is `undefined` or if the `WebAssembly.Memory` constructor fails (some iOS devices might throw when `shared` is `true` due to a bug).

Re: WASI Support in Go

#45

Post by DanielHB »

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?

Technically you don't need a full kernel, edge workers will likely have their own custom trimmed down kernels for running WASM binaries, cutting out a lot of the OS overhead. As long as they implement a limited set of POSIX syscalls they can run WASM binaries, in fact you might even want to limit the WASI syscalls you implement for certain targets.

Re: WASI Support in Go

#46

Post by DanielHB »

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…

Technically you don't need a full kernel, edge workers will likely have their own custom trimmed down kernels for running WASM binaries, cutting out a lot of the OS overhead. As long as they implement a limited set of POSIX syscalls they can run WASM binaries, in fact you might even want to limit the WASI syscalls you implement for certain targets.

There are also other things of great value, for example providing a way to write plugins for cloud-based SaaS solutions, as in you compile your binary, hand it over to your SaaS service and the service itself runs your binary when some event happens. Basically plugins for cloud based stuff, much more powerful and simpler than Web Hooks.

Another example was to write custom database functions, for example, adding a complex math function to postgres so you can do "SELECT myFunc(COLUMN_A, COLUMN_B) FROM TABLE".

Another example was to sandbox plugins for desktop applications (including mods for video games), plugins are a huge security issue when it is native code running in your machine.

These plugin examples the entity that is running the plugin code can limit the syscalls used by your WASI-compatible WASM binary so you don't allow, for example, your video game mod to read/write files outside a specific folder in the file-system

Re: WASI Support in Go

#47

Post by imtringued »

eddythompson80 wrote: post #30
noveltyaccount wrote: post #27

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

Yes, you can run anything anywhere as long as it is Java or a JVM language that does not fundamentally change the object or memory management model.

Re: WASI Support in Go

#48

Post by noveltyaccount »

eddythompson80 wrote: post #30
noveltyaccount wrote: post #27

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

Ha! I didn't say it was a new idea, only that it's the promise :)

Re: WASI Support in Go

#49

Post by pryz »

dilyevsky wrote: post #35
jbrandhorst wrote: post #15

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

The answer is: it's complicated. Which is most of the time the answer in the WASI world.

For this case it's complicated because some runtime supports https://github.com/WebAssembly/threads which mostly contains things like the spec for atomic but not the actual "threads" specs and then some runtimes (i.e wasmtime) also supports https://github.com/WebAssembly/wasi-threads which is one version of the threads. But a new proposal came into play https://github.com/abrown/thread-spawn so ... it's complicated.

Re: WASI Support in Go

#50

Post by dilyevsky »

pryz wrote: post #49
dilyevsky wrote: post #35

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

The answer is: it's complicated. Which is most of the time the answer in the WASI world. For this case it's complicated because some runtime supports https://github.com/WebAssembly/threads which mostly contains things like the spec for atomic but not the actual "threads" specs and then some runtimes (i.e wasmtime) also supports https://github.com/WebAssembly/wasi-threads which is one version of the threads. But a new…

Yes, "it's complicated" is very diplomatic way of putting it after like 5+ years...
Post reply on HN