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

91–99 of 99 posts

Re: Go gets preliminary WebAssembly support

#91

Post by amelius »

candiodari wrote: post #66
crudbug wrote: post #42

Earlier quoted context omitted.

I think the interface can provide the semantics - pass by reference or value etc. Which can be standardized. Then it is upto the languages to implement the interface. IMO the languages designers and developers are better off by looking at the GC solution from top-down rather than bottom-up.

Maybe you should think about what this would mean from the perspective of language designers. That would unearth the main difficulty of such an approach: Every language designer would have to completely redesign it's runtime system just to be able to run on this one backend (in addition to having a new compiler target and linker and debugger and ...). Hoping, of course, that this is possible at all, as many languages…

> Why would they do this ? Why should they do this ?

One answer could be that it would enable multiple languages to interface in a better way, and allow garbage to be collected across language boundaries.

Re: Go gets preliminary WebAssembly support

#93

Post by fredliu »

shurcooL wrote: post #43
fredliu wrote: post #27

How are features like go routines and channels etc going to be supported? or they are not?

They are supported. Similar to how they're supported on other architectures, by having a runtime with a scheduler.

So the run time is in web assembly as well, and "complied" in the final "executable"?

Re: Go gets preliminary WebAssembly support

#94

Post by pjmlp »

jayd16 wrote: post #89
pjmlp wrote: post #58

Earlier quoted context omitted.

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

if we were satisfied with that answer we wouldn't be talking about wasm at all.

It all boils down to politics.

Flash bad, Flash compiled to wasm, good.

Re: Go gets preliminary WebAssembly support

#95

Post by shurcooL »

fredliu wrote: post #93
shurcooL wrote: post #43

Earlier quoted context omitted.

They are supported. Similar to how they're supported on other architectures, by having a runtime with a scheduler.

So the run time is in web assembly as well, and "complied" in the final "executable"?

That's right.

Re: Go gets preliminary WebAssembly support

#96

Post by brobinson »

oelmekki wrote: post #54
brobinson wrote: post #52

Earlier quoted context omitted.

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

Don't forget the "-w" linker flag, too.

Re: Go gets preliminary WebAssembly support

#97

Post by tyingq »

littlestymaar wrote: post #71
tyingq wrote: post #24

Earlier quoted context omitted.

Especially with upcoming features like GC, threads, exceptions, polymorphic inline cache, and more[1]. Looks somewhere in between ASM and something like bytecode for a VM. [1] http://webassembly.org/docs/future-features/

Well, ASM is a bytecode for a VM too … CPU are really complex theses days and you definetly don't run your asm on a dumb piece of silicon, as the phrase “bare metal” seams to imply. And, as a reminder, there's often bugs in that VM. Meltdown was one of them, but there's tons of them.

I see your point, but threading, PIC, exceptions, DOM access, etc, are a level above ASM.

Re: Go gets preliminary WebAssembly support

#98

Post by infogulch »

codetrotter wrote: post #87
brobinson wrote: post #52

Earlier quoted context omitted.

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 remember UPX packed binaries would trigger some antivirus software in the past because packing was so frequently used by virus authors. Does anyone know if this is still the case? Also, can you use UPX on WebAssembly binaries? If so, will that trigger any widely used antivirus software?

UPX just compresses the machine code on disk and decompresses it in memory before execution. WebAssembly executables are delivered via http and can just be compressed with gzip/brotli etc as part of the existing protocols, completely transparently to WA itself.

Granted, UPX is specialized so it might have a slight compression edge over gzip. But layering UPX over WA will require three passes over all the code before it's ready to start (1: browser downloads and executes UPX stub and compressed data. 2: UPX unpacks and reloads uncompressed code. 3: browser re-compiles and executes unpacked code again.) This would completely decimate browsers attempts to make WA startup fast like firefox's streaming compiler [1] that starts compiling it before it's even done downloading.

[1]: https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...

Re: Go gets preliminary WebAssembly support

#99

Post by rkeene2 »

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.

AppFS (http://AppFS.rkeene.org/) supports this
Post reply on HN