Go gets preliminary WebAssembly support

Post by yjftsjthsd-h » Sat, Apr 14, 2018, 2:11 PM UTC

oelmekki wrote: post #64

killercup wrote: post #63

Earlier quoted context omitted.

Please note that upx also compresses your binary contents and decompresses it at runtime. When downloading a WASM file over HTTP, the server can gzip it transparently. It'd be interesting to compare the effects on the size with what upx does (which is more specialized than gzip).

I see, thanks. I used vanilla `strip` on my binary and it did not produce any size gain (so the strip flag of go compiler is plenty enough). Indeed, given how browsers already handle gunziping resources, it's probably best to rely on it. My binary, stripped by the go compiler and gziped, is 525ko (against 480ko using upx).

Post by MikusR » Sat, Apr 14, 2018, 2:33 PM UTC

brobinson wrote: post #52

oelmekki wrote: post #31

Will the binaries be compiled for size optimization, or will they be the same size as usual golang bins? Go binaries, being static and embedding the whole go runtime, tend to be quite big. Now, I don't care about it because 5 or 10MO on my server filesystem is nothing. If I ask every visitor to download 10MO before running my webpage, that will be a problem, though. Is this something we will have to deal with? Or wil…

Half the size of Go binaries you encounter in the wild are debugging symbols. Compile without them and use `upx --ultra-brute` and the binary will be about ~15% of its original size. You still get goroutine stack traces from panics without the debugging symbols.

Post by pcwalton » Sat, Apr 14, 2018, 3:04 PM UTC

amelius wrote: post #76

crudbug wrote: post #6

What are the challenges to provide a standard GC interface that all managed languages can leverage.

I believe that the LLVM project is trying to accomplish this [1]. However, the concurrent, non-pausing GC of GoLang is not easy to match in efficiency. I'd be interested to hear about actual high-quality implementations of GCs in LLVM. And then there's the problem of making it all work efficiently in WASM (which doesn't yet support advanced concepts needed by GCs such as memory barriers). [1] https://llvm.org/docs/Ga…

Post by codetrotter » Sat, Apr 14, 2018, 3:24 PM UTC

brobinson wrote: post #52

oelmekki wrote: post #31

Will the binaries be compiled for size optimization, or will they be the same size as usual golang bins? Go binaries, being static and embedding the whole go runtime, tend to be quite big. Now, I don't care about it because 5 or 10MO on my server filesystem is nothing. If I ask every visitor to download 10MO before running my webpage, that will be a problem, though. Is this something we will have to deal with? Or wil…

Half the size of Go binaries you encounter in the wild are debugging symbols. Compile without them and use `upx --ultra-brute` and the binary will be about ~15% of its original size. You still get goroutine stack traces from panics without the debugging symbols.

Post by jayd16 » Sat, Apr 14, 2018, 4:38 PM UTC

pjmlp wrote: post #58

oelmekki wrote: post #56

Earlier quoted context omitted.

This would be cool: shared objects over internet. Interesting direction to explore.

Oberon, Java, Limbo, .NET, Flash, ActiveX already explored it.