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

11–20 of 99 posts

Re: Go gets preliminary WebAssembly support

#11

Post by jfoutz »

crudbug wrote: post #6

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

allocation characteristics of different languages. Go copies when passing args. java is pass by value, but those values are usually pointers to objects. very different needs.

Re: Go gets preliminary WebAssembly support

#13

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

Re: Go gets preliminary WebAssembly support

#15

Post by teraflop »

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.

Re: Go gets preliminary WebAssembly support

#16

Post by wvenable »

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 allows you to build "native" libraries that can be accessed from JavaScript. There is huge value in that.

Re: Go gets preliminary WebAssembly support

#18

Post by cjfont »

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.

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.

Re: Go gets preliminary WebAssembly support

#19

Post by strkek »

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.

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

Re: Go gets preliminary WebAssembly support

#20

Post by solarkraft »

strkek wrote: post #19
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.

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

That's pretty much what it's supposed to be. Much of the browsery stuff is still supposed to be handled by JS.
Post reply on HN