Hacker News Reader

Comment by pknopf | Hacker News Reader

Go is making a large push to wasm as well. There is a branch/fork with a near complete wasm Go compiler.

I'm interested in seeing how Rust and Go will compare in the future of the web.

Who will win? ;)

I'm not just being diplomatic when I say that hopefully we can avoid the Rust vs. Go debate here. :P WASM is a bid to help future-proof the relevancy of the web in the face of mobile app stores, and seeing many languages embrace it is a good thing, no matter what those languages are. Heck, since WASM is sandboxed anyway it doesn't even matter if you choose C or C++ over Go or Rust, since memory unsafety shouldn't be exploitable from WASM anyway.

Well, it's not exploitable to get out of the sandbox, but there's still interesting data inside the sandbox. For instance, if some website's wasm is parsing the URL to read the URL fragment or something, you could imagine an attacker sending me to a malformed URL, hoping to overflow the URL parser and gain execution with all the cookies of that web page.

True, I suppose I should temper down "shouldn't be exploitable" to "shouldn't be able to provide a stepping stone to system-wide arbitrary code execution".

I think the domains of use will be quite different. Since Rust doesn't require a GC or other runtime support, we envision it being used in specific modules to provide a boost to code otherwise written in JS. See https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with... for example.

By contrast, for a language like Go, it's probably more practical to ship entire apps, rather than embedding in libraries, because there's significantly more overhead in terms of runtime system support.

Let me throw Nim into the mix and say that it has had a JS backend for years now. It's officially supported so it's very stable.

Native WASM support isn't there yet, but if you want extra speed you could combine Nim's JS backend and Nim's C backend + emscripten to compile to WASM. You can see this approach in action in a game called Reel Valley [1][2]. The advantage is that you can access the DOM from Nim using the JS backend (you cannot do that in WASM yet AFAIK).

1 - https://www.youtube.com/watch?v=DmMOIVUeUrE

2 - https://www.facebook.com/reelvalley/

To be clear, Rust has also had support for asm.js and wasm via emscripten for quite a while. We're very enthusiastic about the new LLVM backend though, as it allows for significantly more control, including file size.

> (you cannot do that in WASM yet AFAIK)

wasm can do anything JS can by calling out to JS. What people mean when they ask for "DOM support in WASM" is to have it be direct, skipping the need for the JS call.

https://crates.io/crates/stdweb is an example of using WASM to manipulate the DOM through JS in Rust today.

> Who will win? ;)

Developers. :)

Do they ship a GC with every webpage then or am I misunderstanding how it works?

For now I think every wasm go module will have its own GC.

Each module has to have it's own GC.

In my experience, it's been easier to integrate two languages that have GC (JavaScript and Go) than two languages where only one is GC'd (JavaScript and Rust).

What will the interop with Rust and JavaScript look like? How will pointers be managed?

Since JS and Go do not have the same GC you have the same issue there.

GC's have some kind of inherit reference counting which makes releasing pointers safe, in any direction. You can't do that with C/C++ without something like glib.

Not entirely sure what you are referring to or how it relates to the issue here. If you have two separate heaps (what you have between go and JS) then they will be collected separately. As such you need to somehow keep objects on the other side alive. Worst: in Go the language does not guarantee that the GC won't compact (it doesn't do correctly though). As such you can't even pass pointers to JavaScript, you need to create handles.

I played around with both Go and Rust from Python and the garbage collection made things harder not easier. Now we write lots of Rust modules for Python and managing memory is pretty easy. We have Python wrapper objects that keep one pointer alive.

> GC's have some kind of inherit reference counting which makes releasing pointers safe, in any direction.

It sounds like you're mostly worried about memory leaks, but the primary concern with trying to get two separate GCs to play nicely isn't leaking memory, it's double-frees (both GCs trying to collect the same resource) and use-after-free (code in one language trying to use a resource that's been accidentally collected by the GC of the other language).

If you have reference counting across GC boundaries, you can easily create memory leaks because of reference cycles, e.g. GC 1 cannot release object 1 because it references object 2, and vice versa. (Unless you only allow refs to go one way.)

Great now I get flashbacks to 2005.

IE6 had exactly that issue, the DOM was implemented using COM which has its own GC (refcounting) separate from the regular JS runtime.

If you created a cycle between DOM and JS by, let's say, adding an event handler to a DOM node — thankfully that's something you'd never do when developing web pages & applications — you'd start leaking memory which would survive across page reloads.

There was actually a bit of software called Drip, it was just a webview wrapper (technically an MFC app with a browser COM component), you'd launch it, open your page, click the "blow memory" button and it'd reload the page over and over again listing elements which had survived between reloads.

No major JS implementation uses naive reference counting, because there's no way to break cycles. Cycle collection requires the ability to trace the heap globally. But the JS engine does not have any way to see inside a wasm heap.

> What will the interop with Rust and JavaScript look like? How will pointers be managed?

First, a disclaimer: all of this is extremely early days, and subject to change.

There's two questions hidden here: "what does the workflow look like?" and "how does this work technically?"

Currently, "what does the workflow look like" is this: https://github.com/ashleygwilliams/wasm-pack#%EF%B8%8F--how-...

"how does this work technically" is this: https://github.com/alexcrichton/wasm-bindgen

The former provides a nice workflow that's fundamentally built on the latter.

It's not at all easier to interoperate two separate GC'd languages unless you have one garbage collector to manage them both. Web Assembly does not provide the hooks necessary to integrate GC, and JavaScript does not provide critical features, such as finalizers, that are necessary to do things like break cross-language cycles. Absent that support, manual memory management of DOM objects is necessary, and Rust is going to have a much easier time of that than Go will.

For specific needs I have occasionally made my Go struct constructors (NewFoobar() *Foobar) use malloc ported to Go + mmap to allocate memory and said structs have a .Close() method (think defer foobar.Close()). It worked fine... This is a fine solution/compromise, in 95+% of development solutions you don't want your devs wasting their time managing memory manually, and in the worse cases they will get it wrong.

Almost all compiled languages are now playing with WebAssembly.

So all languages will win, with the exception of JavaScript.

If browser vendors keep moving the browser into a general purpose VM, lets see how long JavaScript keeps being the "browser systems language".

Reply on news.ycombinator.com