3 ms·

IMO I feel like it is going to be a challenge to integrate the GC of another language with the GC of the JavaScript/DOM, and if so we'll be keeping JavaScript g

by zengid 10y ago

IMO I feel like it is going to be a challenge to integrate the GC of another language with the GC of the JavaScript/DOM, and if so we'll be keeping JavaScript going for a while.

weberc2 10y ago
WebAssembly doesn't have a GC, And I don't see any reason why the DOM should be subject to a JS GC.
- zengid 10y ago
  Correct, but python (or haskell or java or whatever) running on top of WASM would, and there are plans to integrate WASM with the other GC's in the browser, however: "'compile the VM' strategies increase the size of distributed code, lose browser devtools integration, can have cross-language cycle-collection problems and miss optimizations that require integration with the browser" [1]. My prev comment was speculative, but my point is that its not going to be a piece of cake to just drop another high-level language on-top of WASM and use it as a 'better' scripting language without having to pay some overhead costs, one being GC issues. [1] https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-only-for-cc-programmers https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...
  - weberc2 10y ago
    I don't know what is meant by "there are plans to integrate WASM with the other GC's in the browser". Is the idea that the browser runs a GC for DOM elements that is separate from the JS VM GC? I wonder if they could follow a model like operating system resources (e.g., file handles) where the process is responsible for managing the resource lifetimes. This would make resource management trivial, and running (for example) Python on WASM would simply mean emitting WASM instructions instead of x86. Of course, lots of other problems remain, for example, downloading an entire runtime or "putting Python on WASM isn't going to magically make it fast". But I don't think the GC should be a particularly large challenge.

by zengid 10y ago

IMO I feel like it is going to be a challenge to integrate the GC of another language with the GC of the JavaScript/DOM, and if so we'll be keeping JavaScript going for a while.

weberc2 10y ago

WebAssembly doesn't have a GC, And I don't see any reason why the DOM should be subject to a JS GC.

zengid 10y ago
Correct, but python (or haskell or java or whatever) running on top of WASM would, and there are plans to integrate WASM with the other GC's in the browser, however: "'compile the VM' strategies increase the size of distributed code, lose browser devtools integration, can have cross-language cycle-collection problems and miss optimizations that require integration with the browser" [1]. My prev comment was speculative, but my point is that its not going to be a piece of cake to just drop another high-level language on-top of WASM and use it as a 'better' scripting language without having to pay some overhead costs, one being GC issues. [1] https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-only-for-cc-programmers https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...
- weberc2 10y ago
  I don't know what is meant by "there are plans to integrate WASM with the other GC's in the browser". Is the idea that the browser runs a GC for DOM elements that is separate from the JS VM GC? I wonder if they could follow a model like operating system resources (e.g., file handles) where the process is responsible for managing the resource lifetimes. This would make resource management trivial, and running (for example) Python on WASM would simply mean emitting WASM instructions instead of x86. Of course, lots of other problems remain, for example, downloading an entire runtime or "putting Python on WASM isn't going to magically make it fast". But I don't think the GC should be a particularly large challenge.