4 ms·

I think the biggest win is https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/mast

I think the biggest win is https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat.... Now instead of asm.js being only for emscripten-compiled code (or other non-GC code) WebAssembly can be used for higher level, GC'd languages. And even better, https://github.com/WebAssembly/design/blob/master/NonWeb.md https://github.com/WebAssembly/design/blob/master/NonWeb.md, means we may get a new, generic, standalone VM out of this which is always good (I hope I'm not reading in to the details too much). As someone who likes to write compilers/transpilers, I look forward to targetting this.

JoshTriplett 11y ago
I'm really hoping that WebAssembly doesn't bake-in higher-level features like garbage collection. That would preclude replacing GC with something better, such as Rust-style memory management. Hopefully this will take more inspiration from actual assembly language and virtual machines, rather than from bytecode languages.
- kevingadd 11y ago
  it's a virtual machine, but it needs to interop with the rest of the web. at some point this probably means support for garbage collected heaps, but it doesn't mean it's a pervasively-GCd VM like Java. Think more like how WebKit, Gecko and Blink have lots of GC infrastructure in their native, un-GCd code.
  - JoshTriplett 11y ago
    Right, it has to interoperate with DOM objects; however, those can be treated as "foreign" object handles owned by the browser and just referenced by WebAssembly. Those objects can't be directly in the WebAssembly "address space"; that would be unsafe. So since they have to be managed separately anyway, they can use whatever memory model the browser uses.
- jlongster 11y ago
  I highly doubt it would ever bake in GC semantics. High-perf stuff like games are the biggest push for this kind of thing, where nobody wants a GC. One of the biggest advantages to asm.js right now is predictable performance because of no GC. Most likely an API will be provided for interacting with a garbage collector, but it's completely optional.
- bryanlarsen 11y ago
  asm.js doesn't include garbage collection and they're initially targetting C/C++, so I highly doubt they're going to add GC any time soon. The linked 'future feature' reads more to me like a mechanism to access the garbage collector already present in the browser to allow interoperability with JS and the DOM.
- azakai 11y ago
  GC support doesn't prevent having Rust-style compile-time memory management. In fact, Rust itself may add a GC at some point.
  - JoshTriplett 11y ago
    As a library, though, which is very different than providing it as an inherent part of a language runtime. I'm hoping WebAssembly doesn't inherently imply a runtime.
    - saosebastiao 11y ago
      How could you have threading without a runtime?
      - JoshTriplett 11y ago
        You can have APIs without a runtime. For instance, the WebAssembly implementation should have a function to spawn a new thread given a function pointer. That should result in a real OS thread running in the same address space. Any further semantics beyond that would be up to the software targeting WebAssembly.
    - deleted 11y ago
      [deleted]
    - azakai 11y ago
      Efficient GC requires tight integration with LLVM, and I assume that means also tight integration with the Rust compiler. I don't think that can be done as a library or even a plugin.
      - iopq 11y ago
        Rust doesn't need an efficient GC like the kind Java has. Most of the resources you need in Rust are freed when they get out of scope. What Rust needs is just a better RC implementation. This is because only a small part of your data is reference counted, so it fits better with how Rust works, so an efficient implementation allows it to combine with ownership semantics to outperform even very advanced generational GCs.
- kodablah 11y ago
  It depends on how you define "bake-in". I consider it "opt-in" but it's important. If you don't offer it at all, you will continue to only see adoption as a target of low-level languages or you will have people reinventing GC on top of WebAssembly. The JS runtime has a quality GC right there, why not allow me to use it if needed (but definitely don't require it)?
the8472 11y ago
also important in my eyes: shared memory threading: https://github.com/WebAssembly/design/blob/master/PostMVP.md#threads https://github.com/WebAssembly/design/blob/master/PostMVP.md... Threads themselves may be "ugly", but to build all the pretty abstractions you need them as foundation.
- BrendanEich 11y ago
  Yet also coming to JS, see https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p.... Not a reason per-se to do wasm, at least in short term. Longer term, great to do full pthread things in wasm and not pollute JS.

JoshTriplett 11y ago

I'm really hoping that WebAssembly doesn't bake-in higher-level features like garbage collection. That would preclude replacing GC with something better, such as Rust-style memory management. Hopefully this will take more inspiration from actual assembly language and virtual machines, rather than from bytecode languages.

kevingadd 11y ago
it's a virtual machine, but it needs to interop with the rest of the web. at some point this probably means support for garbage collected heaps, but it doesn't mean it's a pervasively-GCd VM like Java. Think more like how WebKit, Gecko and Blink have lots of GC infrastructure in their native, un-GCd code.
- JoshTriplett 11y ago
  Right, it has to interoperate with DOM objects; however, those can be treated as "foreign" object handles owned by the browser and just referenced by WebAssembly. Those objects can't be directly in the WebAssembly "address space"; that would be unsafe. So since they have to be managed separately anyway, they can use whatever memory model the browser uses.
jlongster 11y ago
I highly doubt it would ever bake in GC semantics. High-perf stuff like games are the biggest push for this kind of thing, where nobody wants a GC. One of the biggest advantages to asm.js right now is predictable performance because of no GC. Most likely an API will be provided for interacting with a garbage collector, but it's completely optional.
bryanlarsen 11y ago
asm.js doesn't include garbage collection and they're initially targetting C/C++, so I highly doubt they're going to add GC any time soon. The linked 'future feature' reads more to me like a mechanism to access the garbage collector already present in the browser to allow interoperability with JS and the DOM.
azakai 11y ago
GC support doesn't prevent having Rust-style compile-time memory management. In fact, Rust itself may add a GC at some point.
- JoshTriplett 11y ago
  As a library, though, which is very different than providing it as an inherent part of a language runtime. I'm hoping WebAssembly doesn't inherently imply a runtime.
  - saosebastiao 11y ago
    How could you have threading without a runtime?
    - JoshTriplett 11y ago
      You can have APIs without a runtime. For instance, the WebAssembly implementation should have a function to spawn a new thread given a function pointer. That should result in a real OS thread running in the same address space. Any further semantics beyond that would be up to the software targeting WebAssembly.
  - deleted 11y ago
    [deleted]
  - azakai 11y ago
    Efficient GC requires tight integration with LLVM, and I assume that means also tight integration with the Rust compiler. I don't think that can be done as a library or even a plugin.
    - iopq 11y ago
      Rust doesn't need an efficient GC like the kind Java has. Most of the resources you need in Rust are freed when they get out of scope. What Rust needs is just a better RC implementation. This is because only a small part of your data is reference counted, so it fits better with how Rust works, so an efficient implementation allows it to combine with ownership semantics to outperform even very advanced generational GCs.
kodablah 11y ago
It depends on how you define "bake-in". I consider it "opt-in" but it's important. If you don't offer it at all, you will continue to only see adoption as a target of low-level languages or you will have people reinventing GC on top of WebAssembly. The JS runtime has a quality GC right there, why not allow me to use it if needed (but definitely don't require it)?

the8472 11y ago

also important in my eyes: shared memory threading: https://github.com/WebAssembly/design/blob/master/PostMVP.md#threads https://github.com/WebAssembly/design/blob/master/PostMVP.md... Threads themselves may be "ugly", but to build all the pretty abstractions you need them as foundation.

BrendanEich 11y ago
Yet also coming to JS, see https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p.... Not a reason per-se to do wasm, at least in short term. Longer term, great to do full pthread things in wasm and not pollute JS.