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

WebAssembly architecture for Go

docs.google.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: WebAssembly architecture for Go

#51

Post by codedokode »

mutagen wrote: post #32

What kind of WASM file sizes can we expect? I know some work has gone into shrinking Go executables, especially in 1.7, but will we be able to produce something like the 15KB Rust Hello World WASMs? Go has a fantastic stdlib but it hasn’t prioritized web optimized file sizes (yet). I’m looking forward to the results of this work!

In Google's Doubleclick for Publishers UI they use Dart apps. The page loads several "apps" compiled to JS, each of which weights more than 2 Mb (even the "changelog" app). Page loads very slowly. So I would expect something similar for Go.

Re: WebAssembly architecture for Go

#52

Post by k__ »

steveklabnik wrote: post #15
swsieber wrote: post #12

Earlier quoted context omitted.

I was under the impression that WASM does not have one.

Wasm doesn't have one yet , but it's a future extension to to spec. You can, of course, compile your GC in today, and it will work. Wasm's integrated support will mean re-using the existing GC, which means smaller code size. Side note: most people thought this would be a precursor to DOM support, but the new "host bindings" proposal opens up DOM support without needing GC support, and many people believe that now the…

Are GC implementations transparent for the languages?

Can Go simply run with the WASM GC or does it need some specific type of GC?

Re: WebAssembly architecture for Go

#54

Post by steveklabnik »

mutagen wrote: post #32

What kind of WASM file sizes can we expect? I know some work has gone into shrinking Go executables, especially in 1.7, but will we be able to produce something like the 15KB Rust Hello World WASMs? Go has a fantastic stdlib but it hasn’t prioritized web optimized file sizes (yet). I’m looking forward to the results of this work!

A "hello world" in Rust is ~100 bytes; the more stuff you use, the bigger it gets, as less of the stdlib can be removed. The biggie is an allocator, which adds some size, but you can use things like https://github.com/fitzgen/wee_alloc and it's less than a kilobyte...

Re: WebAssembly architecture for Go

#55

Post by steveklabnik »

amelius wrote: post #53

Strange that wasm doesn't support go-to instructions. Didn't they see the need for it coming? Most compiler backends need it, I suppose.

> Didn't they see the need for it coming?

Wasm exists because it's small and incremental; there's lots of stuff that's needed, but not in the initial spec. As long as it can be added in the future, that's what matters.

Re: WebAssembly architecture for Go

#56

Post by swsieber »

jononor wrote: post #48
mlevental wrote: post #34

Earlier quoted context omitted.

but i'm asking what are some webasm languages/backends/use cases that aren't a JS interpreter?

There is a work ongoing to enable WASM to be used for Etherum smart contracts, replacing the custom VM/bytecode. One could use WASM for reconfigurable on-edge computing, all the way down to microcontrollers.

WASM for Ethereum would be amazing. There are a lot of languages with much better safety stories than the current one.

Re: WebAssembly architecture for Go

#57

Post by steveklabnik »

k__ wrote: post #52
steveklabnik wrote: post #15

Earlier quoted context omitted.

Wasm doesn't have one yet , but it's a future extension to to spec. You can, of course, compile your GC in today, and it will work. Wasm's integrated support will mean re-using the existing GC, which means smaller code size. Side note: most people thought this would be a precursor to DOM support, but the new "host bindings" proposal opens up DOM support without needing GC support, and many people believe that now the…

Are GC implementations transparent for the languages? Can Go simply run with the WASM GC or does it need some specific type of GC?

"the WASM GC" only exists as a proposal, and proposals can change before they land. I don't know enough about it to say, and even if I did, it might be invalid by the time things are actually accepted.

See https://github.com/WebAssembly/gc for the current proposal.

Re: WebAssembly architecture for Go

#58

Post by obl »

amelius wrote: post #53

Strange that wasm doesn't support go-to instructions. Didn't they see the need for it coming? Most compiler backends need it, I suppose.

I'm assuming it's because they wanted existing js/asm.js JITs to easily accept wasm, and those only see structured control flow.

Re: WebAssembly architecture for Go

#59

Post by slrz »

sitkack wrote: post #26
goalieca wrote: post #7

Earlier quoted context omitted.

Follow-up question, why can't LLVM -> Web Assembly solve the problem?

x86 elf -> wasm could solve this problem.

No, it wouldn't. At that point you already lost lots of information and your only option is to faithfully reproduce the behaviour of the x86 machine.

You can still do it, of course and performance isn't even that bad. See Fabrice Bellard's x86 emulator using asm.js.

https://bellard.org/jslinux/tech.html

Re: WebAssembly architecture for Go

#60

Post by sitkack »

slrz wrote: post #59
sitkack wrote: post #26

Earlier quoted context omitted.

x86 elf -> wasm could solve this problem.

No, it wouldn't. At that point you already lost lots of information and your only option is to faithfully reproduce the behaviour of the x86 machine. You can still do it, of course and performance isn't even that bad. See Fabrice Bellard's x86 emulator using asm.js. https://bellard.org/jslinux/tech.html

Ok, pick a better ISA, like RISC-V.
Post reply on HN