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

Go gets preliminary WebAssembly support

go-review.googlesource.com

Post reply on HN
Print view View original

51–60 of 99 posts

Re: Go gets preliminary WebAssembly support

#51

Post by jayd16 »

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…

Hmm, maybe language runetimes can be dynamically linked and hosted by the language maintainers. Everyone imports the official library so the odds of the user already having most of everything cached is high.

Re: Go gets preliminary WebAssembly support

#52

Post by brobinson »

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.

Re: Go gets preliminary WebAssembly support

#53

Post by hawski »

jayd16 wrote: post #51
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…

Hmm, maybe language runetimes can be dynamically linked and hosted by the language maintainers. Everyone imports the official library so the odds of the user already having most of everything cached is high.

Aren't cache gained savings a myth? Browsers have cache in magnitude of tens of megabytes and most sites have different versions of everything.

Re: Go gets preliminary WebAssembly support

#54

Post by oelmekki »

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.

I didn't know go compiler allowed to build without those, thanks.

I've just tried on a go binary that was 2.4MO. After building it with `go build -ldflags=-s .`, it's 1.6MO. After stripping with upx, it's 480ko (and still works, and has panic stack traces).

Re: Go gets preliminary WebAssembly support

#55

Post by oelmekki »

uluyol wrote: post #35
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…

I don't know much about wasm, but I imagine that most wasm binaries will be statically linked. The runtime does add overhead but I'd like to know how much compared to what you see with reasonably complex rust wasm code.

Yeah indeed, and if web development prefigure anything for wasm, we can expect apps to quickly have a lot of dependencies built in. I guess we'll get used again to "please wait, loading" screens :)

Re: Go gets preliminary WebAssembly support

#56

Post by oelmekki »

jayd16 wrote: post #51
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…

Hmm, maybe language runetimes can be dynamically linked and hosted by the language maintainers. Everyone imports the official library so the odds of the user already having most of everything cached is high.

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

Re: Go gets preliminary WebAssembly support

#57

Post by pjmlp »

oelmekki wrote: post #55
uluyol wrote: post #35

Earlier quoted context omitted.

I don't know much about wasm, but I imagine that most wasm binaries will be statically linked. The runtime does add overhead but I'd like to know how much compared to what you see with reasonably complex rust wasm code.

Yeah indeed, and if web development prefigure anything for wasm, we can expect apps to quickly have a lot of dependencies built in. I guess we'll get used again to "please wait, loading" screens :)

I still get "please wait, loading" screens in JS heavy sites, specially those that go to the extreme of using JS to display static text.

Re: Go gets preliminary WebAssembly support

#58

Post by pjmlp »

oelmekki wrote: post #56
jayd16 wrote: post #51

Earlier quoted context omitted.

Hmm, maybe language runetimes can be dynamically linked and hosted by the language maintainers. Everyone imports the official library so the odds of the user already having most of everything cached is high.

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

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

Re: Go gets preliminary WebAssembly support

#59

Post by sbinet »

mappu wrote: post #46
bm1362 wrote: post #26

Earlier quoted context omitted.

Off topic: is it possible to build a JIT compiler for Go or does the runtime prevent that?

I think it's certainly possible. The Go compiler is AOT and there are Go interpreters (in various stages of completeness), it would be a matter of interpreting the application - finding hot functions in execution traces - and swapping them out with background-compiled versions. Some work would be needed to keep the GC happy between interpreted and compiled functions, but no more complex than JS JITs have to do. Go's…

there's actually (the beginning of) an interpreter in Go, for Go, that consummes wasm :)

https://github.com/go-interpreter/wagon

Re: Go gets preliminary WebAssembly support

#60

Post by callahad »

teraflop wrote: post #15
chrissnell wrote: post #10

Could this be used to get native gRPC support for the browser?

WebAssembly doesn't provide any functional capabilities that aren't already accessible to JavaScript. This change does not really enable a browser to do anything more "natively" than it already could, other than run code that's written in Go.

Do 64-bit integers count? Because those aren't available in JavaScript (yet.)
Post reply on HN