
Go gets preliminary WebAssembly support - ricksnyke
https://go-review.googlesource.com/c/go/+/102835
======
oelmekki
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 will this be a lesser featured
go implementation?

~~~
brobinson
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.

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

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

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

~~~
yjftsjthsd-h
Could it also be that Go encodes symbols in a way that strip can't read, or is
is just standard ELF stuff?

------
misterbowfinger
Hey so question - WebAssembly can't access the DOM right? What's the whole
point then, avoid Javascript? If we can't just swap out all the gnarly JS
garbage whole-hog, I don't see where the business value is, given that there's
plenty of language-to-js libraries.

~~~
strkek
As weird as this might sound, I see WebAsssembly more like a portable shared
library format than a JavaScript replacement.

~~~
solarkraft
That's pretty much what it's supposed to be. Much of the browsery stuff is
still supposed to be handled by JS.

------
exebook
Article mentions that the compiled code will also run on Node.js, does it mean
it will be possible to use all zillions of NPM modules from Go at some point
in time?

~~~
colonelxc
Thus solving Go's dependency management problem once and for all.

~~~
eikenberry
Solving it by giving it a worse one.

~~~
littlestymaar
Worse than pulling master on github, really ?

Npm has issues, but it's still way better than the state of the art of
dependency management in Go.

Left-pad was bad but the problem was fixed on npm's side after a couple hours.
Go's equivalent isn't fixable:
[https://mobile.twitter.com/davecheney/status/855049071307792...](https://mobile.twitter.com/davecheney/status/855049071307792384)

~~~
mappu
Pulling master on github isn't the "state of the art" for Go (it's dep and
vgo).

~~~
littlestymaar
`dep` _is_ pulling directly from github … And `vgo`, while promising, is still
a protype not ready for production[0].

[0]: [https://github.com/golang/go/wiki/vgo#current-
state](https://github.com/golang/go/wiki/vgo#current-state)

~~~
cdoxsey
commit your vendor folder

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

~~~
rqs
Dig a little deeper: [https://docs.google.com/document/d/131vjr4DH6JFnb-
blm_uRdaC0...](https://docs.google.com/document/d/131vjr4DH6JFnb-
blm_uRdaC0_Nv3OUwjEY5qVCxCup4)

Mentions:

> Currently WebAssembly has no threads, but they are on the roadmap. Most Go
> code can run fine on a single thread. The only drawback is that “sysmon” is
> not available, thus there is no preemption of goroutines.

~~~
shurcooL
"thread" here refers to logical thread. A single logical thread can be used to
run any number of goroutines, just one at a time.

~~~
candiodari
Go does both preemptive and cooperative multitasking, so there is no relation
to the number of goroutines "running" and the number of threads (or for that
matter, cpus or cores).

[https://en.wikipedia.org/wiki/Cooperative_multitasking](https://en.wikipedia.org/wiki/Cooperative_multitasking)

How this works in Go ? Thoroughly simplified it happens because at every flow
control statement in Go, including function calls, what really happens is
that, first, Go asks it's runtime to switch goroutines, and only then goes
into the if, or subroutine, or ...

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

~~~
amelius
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/GarbageCollection.html#goals-and-
non-g...](https://llvm.org/docs/GarbageCollection.html#goals-and-non-goals)

~~~
pcwalton
I believe the only user of the LLVM GC infrastructure is Azul's JVM. Azul is
of course famous for Azul C4, which is a superior GC to that of Go.

------
agnivade
There are still some commits under review. I would wait until the tracking
issue is closed.

------
mappu
Can this be used with CGO_ENABLED=1 if CC is emscripten?

~~~
caspervonb
Currently it's not supported, see
[https://github.com/golang/go/blob/a9ba3e30acf004a57fbc1288d5...](https://github.com/golang/go/blob/a9ba3e30acf004a57fbc1288d5cea6bae74d06e8/src/cmd/dist/build.go#L1359-L1399)

------
Illniyar
I thought webassembly has no GC. Is this implementing a GC for go as well, or
did something change?

~~~
fulafel
It is a new target for the standard Go compiler/runtime, so yes.

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

~~~
teraflop
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.

~~~
skybrian
And that's not really new either, due to GopherJS [1]

[https://github.com/gopherjs/gopherjs](https://github.com/gopherjs/gopherjs)

------
TekMol
Somehow I have the feeling this whole Webassembly thing will be a giant flop.

Tech people seem to think that making code run twice as fast is a huge step
forward. But in the grand scheme of things its nothing.

------
blaisio
I really wish WebAssembly did not use the word "Assembly". It doesn't really
resemble any actual assembly language. And if you look at the comments in this
thread, for example, a lot of people think it's letting you have something
like arbitrary machine code.

~~~
teabee89
I really wish WebAssembly didn’t use the word “Web”. Its best usecase is for
the server. It just happens to also be great for challenging JavaScript in the
browser.

~~~
SiVal
Why do you say its "best" usecase is for the server? I'm actually asking, not
disputing, but I'm asking because it seems the big selling point of WASM,
running new types of code that you couldn't run before, was never a problem on
the server, where you can run whatever you like.

So, I'm assuming you have something else in mind, and I'm wondering what it
is.

------
hasharray
This is great; looks like it's still fairly rough but interesting that GC
languages are making due with what's there in the MVP of WebAssembly right
now.

Wonder how it works? does it use the regular call stacks or construct it's own
and so on?

~~~
_greim_
From this: [https://docs.google.com/document/d/131vjr4DH6JFnb-
blm_uRdaC0...](https://docs.google.com/document/d/131vjr4DH6JFnb-
blm_uRdaC0_Nv3OUwjEY5qVCxCup4/edit)

> Go’s garbage collection is fully supported. WebAssembly is planning to add
> its own garbage collection, but it is hard to imagine that it would yield a
> better performance than Go’s own GC which is specifically tailored to Go’s
> needs.

Presumably a runtime will be compiled into the wasm output, including Go's
garbage collector.

~~~
daurnimator
But Go's garbage collector can't traverse the DOM.

------
jhoechtl
A GCed language Go is with split stack semantics Webassembly will only be a
second class citizen.

~~~
mappu
Split stacks are no longer used, as of Go 1.3 (2014).

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

~~~
mappu
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 GC at
least already has the capability to move objects, that's a help.

In reality, JITs are used to infer typing information that dynamic languages
only discover at runtime. Go doesn't have this problem, and an AOT can
probably discover stronger optimizations.

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

[https://github.com/go-interpreter/wagon](https://github.com/go-
interpreter/wagon)

