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

71–80 of 99 posts

Re: Go gets preliminary WebAssembly support

#71

Post by littlestymaar »

tyingq wrote: post #24
blaisio wrote: post #13

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.

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.

Re: Go gets preliminary WebAssembly support

#72

Post by mappu »

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.

Even building without debugging symbols, a lot of the remaining size comes from runtime type information and method/function/struct names, used in reflection, which there's no way to remove. That also has some reverse-engineering implications.

Re: Go gets preliminary WebAssembly support

#73

Post by mappu »

littlestymaar wrote: post #69
eikenberry wrote: post #32

Earlier quoted context omitted.

Solving it by giving it a worse one.

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

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

Re: Go gets preliminary WebAssembly support

#74

Post by pjmlp »

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.

To add to that, that it was always how most CPUs were developed.

Pure RISC CPUs were the outliers, but coupling RISC ideas with micro-code turned out to win the match.

Even modern ARM versions use micro-code on their CPUs.

Re: Go gets preliminary WebAssembly support

#75

Post by mappu »

littlestymaar wrote: post #70
cjfont wrote: post #18

Earlier quoted context omitted.

So there's a lot of other things that can be done on the client other than interacting with the DOM. In particular, applications that render intense graphics, or manage a local database could GREATLY benefit from more efficient compiled code, and this would open up possibilities that the current JS engine wouldn't be able to deliver.

That's indeed true, but I wouldn't count Go as an example of “efficient compiled code”. It's way behind of GCC or LLVM in terms of optimizations, and being ahead-of-time-compiled is a drawback, not an asset.

Both GCC and LLVM can compile Go code.

Re: Go gets preliminary WebAssembly support

#76

Post by amelius »

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/GarbageCollection.html#goals-and-non-g...

Re: Go gets preliminary WebAssembly support

#77

Post by littlestymaar »

mappu wrote: post #73
littlestymaar wrote: post #69

Earlier quoted context omitted.

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

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

`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

Re: Go gets preliminary WebAssembly support

#78

Post by tomatsu »

exebook wrote: post #22

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?

In Chrome and Node, Wasm code is executed by V8.

V8 can be embedded in C/C++/Go/etc applications. That allows you to use JS for scripting. This is quite different from compiling to Wasm, though.

Re: Go gets preliminary WebAssembly support

#79

Post by littlestymaar »

mappu wrote: post #75
littlestymaar wrote: post #70

Earlier quoted context omitted.

That's indeed true, but I wouldn't count Go as an example of “efficient compiled code”. It's way behind of GCC or LLVM in terms of optimizations, and being ahead-of-time-compiled is a drawback, not an asset.

Both GCC and LLVM can compile Go code.

That's a bit of an oversimplification.

About llvm, there's a WIP prototype that doesn't quite work yet[0].

And about GCC, GccGo is behind in Go's version. GCC 7 only supports Go 1.8 (with caveats). Also, it had issues at some point[2] (but this is from 2014, it may have been fixed since then).

And, on a more pragmatic point of view, when talking about Go, the huge majority talks about Go compiled with the standard Go compiler. That's why you here a lot of positive feedback about compile-times for instance.

[0]: http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT [1]: https://golang.org/doc/install/gccgo#Releases [2]: https://talks.golang.org/2014/gocon-tokyo.slide#54

Re: Go gets preliminary WebAssembly support

#80

Post by cdoxsey »

littlestymaar wrote: post #77
mappu wrote: post #73

Earlier quoted context omitted.

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

`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

commit your vendor folder
Post reply on HN