Go gets preliminary WebAssembly support • Hacker News Board

Re: Go gets preliminary WebAssembly support

#21

Post by dangerbird2 » Fri, Apr 13, 2018, 11:02 PM UTC

misterbowfinger wrote: post #7

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.

Webassembly uses a javascript "glue" for accessing the DOM. The point of Webassembly is not to just be an alternative to javascript; it's to have a binary web program format that runs at close to native speeds. This makes it extremely useful for porting C/C++ applications, especially games, to the browser.

Re: Go gets preliminary WebAssembly support

#22

Post by exebook » Fri, Apr 13, 2018, 11:04 PM UTC

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?

Re: Go gets preliminary WebAssembly support

#23

Post by colonelxc » Fri, Apr 13, 2018, 11:06 PM UTC

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?

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

Re: Go gets preliminary WebAssembly support

#24

Post by tyingq » Fri, Apr 13, 2018, 11:07 PM UTC

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/

Re: Go gets preliminary WebAssembly support

#25

Post by tyingq » Fri, Apr 13, 2018, 11:16 PM UTC

misterbowfinger wrote: post #7

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.

DOM access is planned. https://github.com/WebAssembly/design/issues/1079. (first bullet point)

Re: Go gets preliminary WebAssembly support

#26

Post by bm1362 » Fri, Apr 13, 2018, 11:24 PM UTC

mappu wrote: post #12

jhoechtl wrote: post #3

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

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

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

Re: Go gets preliminary WebAssembly support

#27

Post by fredliu » Fri, Apr 13, 2018, 11:39 PM UTC

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

Re: Go gets preliminary WebAssembly support

#28

Post by teabee89 » Fri, Apr 13, 2018, 11:50 PM UTC

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.

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.

Re: Go gets preliminary WebAssembly support

#29

Post by fnord123 » Fri, Apr 13, 2018, 11:59 PM UTC

chrissnell wrote: post #10

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

Why would you use this and not GC-free C bindings? (Clang can compile to WASM).

Re: Go gets preliminary WebAssembly support

#30

Post by pcwalton » Sat, Apr 14, 2018, 12:05 AM UTC

crudbug wrote: post #6

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

Tracing objects in the heap (and/or stack). The GC has to be able to find all the outgoing pointers from any object, and usually the types of the objects pointed to by those pointers as well. Different language runtimes store objects in memory in different ways.