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.
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).
> (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.
Developers. :)
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?
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.
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.
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).
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.
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".
I'm interested in seeing how Rust and Go will compare in the future of the web.
Who will win? ;)