6 ms·

> As I understand it, there's no current plans for WebAssembly to include a garbage collector There are plans to add a garbage collector. See https://hacks.moz

> As I understand it, there's no current plans for WebAssembly to include a garbage collector There are plans to add a garbage collector. See https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/ https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu.... But meanwhile, Webassembly is mainly just for C and Rust.

steveklabnik 8y ago
Note that’s more “integrate with a host’s GC” than it is “add a GC.” A subtle but important difference.
hu3 8y ago
> Webassembly is mainly just for C and Rust That's absolutely incorrect. Go and .NET can target WASM for quite a while now. Microsoft's Blazor is specially interesting. Their FlightFinder demo written in pure C# renders a beautiful app: https://i.imgur.com/HHFkB1E.png https://i.imgur.com/HHFkB1E.png Code here: https://github.com/aspnet/samples/tree/master/samples/aspnetcore/blazor/FlightFinder https://github.com/aspnet/samples/tree/master/samples/aspnet...
- colordrops 8y ago
  Right but those languages compile in their own garbage collector. That's not the same as a VM provided garbage collector, and furthermore, the GC used in browsers also manages DOM allocations, and thus directly interfacing the DOM without JS is impossible until the VM GC is implemented.
- steveklabnik 8y ago
  This is literally true, but last I checked, Go’s minimum size was about a megabyte, Blazor’s was 300k, and Rust’s is ~100 bytes. That’s what your parent means.
  - bayesian_horse 8y ago
    That's only a problem for more traditional websites. For applications 1MB is just not an issue. I imagine there will be some kind of CDN/cache to distribute runtimes. Maybe even a WASM package management system for browsers?
    - steveklabnik 8y ago
      As I said above, this is true for an app, but you wouldn’t want it for every library. That adds up very quick. A CDN may happen; there’s some details that make it tough. We’ll see. npm is already that package manager :)
      - bayesian_horse 8y ago
        No need to replace the millions of packages in npm. I predict there will never be a shortage of new javascript frameworks... No, npm is not THAT package manager. What I am talking about is a way for a user's Browser to download for example a Python 3.7.1 runtime (and similar packages) once, and use it on different sites and applications. In the simplest form Google or Python.org could serve these files on a CDN. In a more complicated form you could run an application on a range of Python versions, and only download updates when you want and need them.
        steveklabnik 8y ago
        Ah, yeah. We’ll see if it happens.
      - deleted 8y ago
        [deleted]
      - krapp 8y ago
        >npm is already that package manager :) No, we should be working to replace NPM and the bad influence of the javascript community, not double down on their ubiquity. We should be able to do a lot better than sticking with NPM and wrapping everything in Chromium.
  - hu3 8y ago
    No, parent clearly wrote that Webassembly is limited to Rust and C due to having no Garbage Collection. Which, as I demonstrated, is just wrong.
danShumway 8y ago
The "problem" with integrating with the host gc is that it means language who have subtly different approaches to garbage collection can't trust compiled code behavior to be identical in the browser. This is probably not a terrible thing, since a native garbage collector in WASM (unless it was designed in an extremely simplistic, low-level form) would also probably not be suitable for the diversity of the languages that want to include one. It is (probably) better for individual languages to write their own, even if that increases binary sizes.
- SquareWheel 8y ago
  It would be neat if they could be cached as language-specific GCs, rather than having to be bundled individually with each application.
  - danShumway 8y ago
    This is something that interests me as well. If you have separate WASM binaries, right now they have to be on separate threads. For many languages, that may not matter, but it would be interesting to see if there was some way to split up a WASM binary on the same thread and apply caching to some of it.
- skybrian 8y ago
  Of course, if you have a bunch of languages that compile to JavaScript, they all share the same low-level object layout and garbage collector. This VM has a lot of momentum. The problem is that languages that are genuinely different from JavaScript (such as Dart and Go via gopher) have their own static linkers that generate a big blob of JavaScript. To really do interop right, you need to share a common linker and data format for public API calls. And to make this efficient, it needs to handle inlining and tree-shaking. At that point you might as well use JavaScript or a light overlay language like TypeScript. With wasm, similarly, a common language runtime should probably have its own linker that combines and optimizes libraries and emits a wasm file.
fulafel 8y ago
That "integration with the browser’s garbage collector" feature in the webassembly roadmap doesn't mean the inclusion of a GC - it means there will be a mechanism by which a WASM-implemented GC can cooperate with the browser GC. (There seem to be additional long term ideas int he wasm design repos for adding more GC support, but they seem vague at this point and it's not clear how interested browser vendors or language implementors are)

steveklabnik 8y ago

Note that’s more “integrate with a host’s GC” than it is “add a GC.” A subtle but important difference.

hu3 8y ago

> Webassembly is mainly just for C and Rust That's absolutely incorrect. Go and .NET can target WASM for quite a while now. Microsoft's Blazor is specially interesting. Their FlightFinder demo written in pure C# renders a beautiful app: https://i.imgur.com/HHFkB1E.png https://i.imgur.com/HHFkB1E.png Code here: https://github.com/aspnet/samples/tree/master/samples/aspnetcore/blazor/FlightFinder https://github.com/aspnet/samples/tree/master/samples/aspnet...

colordrops 8y ago
Right but those languages compile in their own garbage collector. That's not the same as a VM provided garbage collector, and furthermore, the GC used in browsers also manages DOM allocations, and thus directly interfacing the DOM without JS is impossible until the VM GC is implemented.
steveklabnik 8y ago
This is literally true, but last I checked, Go’s minimum size was about a megabyte, Blazor’s was 300k, and Rust’s is ~100 bytes. That’s what your parent means.
- bayesian_horse 8y ago
  That's only a problem for more traditional websites. For applications 1MB is just not an issue. I imagine there will be some kind of CDN/cache to distribute runtimes. Maybe even a WASM package management system for browsers?
  - steveklabnik 8y ago
    As I said above, this is true for an app, but you wouldn’t want it for every library. That adds up very quick. A CDN may happen; there’s some details that make it tough. We’ll see. npm is already that package manager :)
    - bayesian_horse 8y ago
      No need to replace the millions of packages in npm. I predict there will never be a shortage of new javascript frameworks... No, npm is not THAT package manager. What I am talking about is a way for a user's Browser to download for example a Python 3.7.1 runtime (and similar packages) once, and use it on different sites and applications. In the simplest form Google or Python.org could serve these files on a CDN. In a more complicated form you could run an application on a range of Python versions, and only download updates when you want and need them.
      - steveklabnik 8y ago
        Ah, yeah. We’ll see if it happens.
    - deleted 8y ago
      [deleted]
    - krapp 8y ago
      >npm is already that package manager :) No, we should be working to replace NPM and the bad influence of the javascript community, not double down on their ubiquity. We should be able to do a lot better than sticking with NPM and wrapping everything in Chromium.
- hu3 8y ago
  No, parent clearly wrote that Webassembly is limited to Rust and C due to having no Garbage Collection. Which, as I demonstrated, is just wrong.

danShumway 8y ago

The "problem" with integrating with the host gc is that it means language who have subtly different approaches to garbage collection can't trust compiled code behavior to be identical in the browser. This is probably not a terrible thing, since a native garbage collector in WASM (unless it was designed in an extremely simplistic, low-level form) would also probably not be suitable for the diversity of the languages that want to include one. It is (probably) better for individual languages to write their own, even if that increases binary sizes.

SquareWheel 8y ago
It would be neat if they could be cached as language-specific GCs, rather than having to be bundled individually with each application.
- danShumway 8y ago
  This is something that interests me as well. If you have separate WASM binaries, right now they have to be on separate threads. For many languages, that may not matter, but it would be interesting to see if there was some way to split up a WASM binary on the same thread and apply caching to some of it.
skybrian 8y ago
Of course, if you have a bunch of languages that compile to JavaScript, they all share the same low-level object layout and garbage collector. This VM has a lot of momentum. The problem is that languages that are genuinely different from JavaScript (such as Dart and Go via gopher) have their own static linkers that generate a big blob of JavaScript. To really do interop right, you need to share a common linker and data format for public API calls. And to make this efficient, it needs to handle inlining and tree-shaking. At that point you might as well use JavaScript or a light overlay language like TypeScript. With wasm, similarly, a common language runtime should probably have its own linker that combines and optimizes libraries and emits a wasm file.

fulafel 8y ago

That "integration with the browser’s garbage collector" feature in the webassembly roadmap doesn't mean the inclusion of a GC - it means there will be a mechanism by which a WASM-implemented GC can cooperate with the browser GC. (There seem to be additional long term ideas int he wasm design repos for adding more GC support, but they seem vague at this point and it's not clear how interested browser vendors or language implementors are)