Hacker News Reader

Comment by ballenf | Hacker News Reader

The most popular language that you can't compile into wasm is Javascript?

This issue was closed 12 hours ago: https://github.com/WebAssembly/design/issues/219

I know it's cliche and been written about ad nauseum, but this really does feel like the trojan horse threat to MS, Apple and Android.

View on HN

What exactly is the "threat" to those players here, wasm?

It baffles me when people are asking for "a mechanism (aka hidden behind-the-scenes magic) for objects and GC" in an assembly language =)

It makes complete sense to ask for GC support. Even if it's never used to implement GC-d languages targeting WebAssembly, it's still important for integration with the Javascript GC.

(I imagine the threat here is that the more things can be deployed as web apps, the less they depend on any particular desktop OS.)

Why not write the GC in WebAssembly?

How would you implement determining the root set? So how would you detect which local variables reference an object? The Gc needs to keep these objects alive.

AFAIK even conservative root-scanning is not possible right now. Please correct me if I am wrong: With the current bytecodes it is only possible to access the heap but not the stack. To make things worse, object references could also be in registers.

Two reasons, beyond the sibling comment's notes that it's currently impossible:

1) You can't integrate it with the Javascript GC for interacting with the DOM and other JS-side objects

2) Now you have to distribute the GC with every app that uses it

WebAssembly is mostly about being a faster-to-parse version of asm.js. asm.js is an easier-to-optimize subset of Javascript. If it were easy to transform any arbitrary Javascript into asm.js, then browser makers would just apply that transformation themselves (or more likely, write the optimizations so they don't target only a subset).

Reply on news.ycombinator.com