4 ms·

It didn't click until just now that rust is very naturally suited to WebAssembly due to its lack of garbage collection. As I understand it, there's no current p

It didn't click until just now that rust is very naturally suited to WebAssembly due to its lack of garbage collection. As I understand it, there's no current plans for WebAssembly to include a garbage collector, so higher level languages that want to compile to it will need to bundle their own, increasing the size of the download quite a bit.

azangru 8y ago
> 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]
        8y ago
- 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
Yep! This is a key insight. Even beyond that, there are two approaches you can take: writing your app in wasm, or writing libraries in wasm. Languages with larger runtimes may work for apps, but you don’t want to use them for libraries, because then you lug around every runtime for every language used. Even once wasm can integrate with the host’s GC, non-GC’d languages will have a place in implementing core libraries, for the same reason those languages have c extensions rather than extensions in other large runtime languages today.
- whateveracct 8y ago
  This only applies to libraries served from separate locations though, right? No issue writing a Haskell library for wasm and then having consumers compile their app leveraging your library (at which point it's bundled with the RTS)
  - steveklabnik 8y ago
    I’m not sure what the serving part has to do with it; if I have a ruby library and a python library and I use them from a Haskell app, I’m getting three runtimes, regardless of if they’re bundled together or not.
    - whateveracct 8y ago
      Oh ok. So it's the same as native software exactly then. That's still nice!
- deleted 8y ago
  [deleted]
banachtarski 8y ago
The word "assembly" should have clued you in haha. And the "observation" applies to any natively compiled language, garbage collector or otherwise.
bayesian_horse 8y ago
There are plans to get garbage collection support into WASM, but GC is already possible, just not native. In my opinion the major benefit of WASM over Javascript is that it allows different runtimes to be used in browsers. Python for example has the pyodide project, which works quite well. But its download sizes are totally ridiculous. Which may not matter for certain applications, and even then, there should be a way to host and cache such runtimes for multiple applications or websites.
- k__ 8y ago
  They don't wanna "add GC" they wanna add the optiom to usethe GC of the host system, the JS runtime. Don't know how this will play with other languages.
fulafel 8y ago
GC code size can be pretty small. A mark & sweep GC is only a few kilobytes.

azangru 8y ago

> 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]
      - 8y ago
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

Yep! This is a key insight. Even beyond that, there are two approaches you can take: writing your app in wasm, or writing libraries in wasm. Languages with larger runtimes may work for apps, but you don’t want to use them for libraries, because then you lug around every runtime for every language used. Even once wasm can integrate with the host’s GC, non-GC’d languages will have a place in implementing core libraries, for the same reason those languages have c extensions rather than extensions in other large runtime languages today.

whateveracct 8y ago
This only applies to libraries served from separate locations though, right? No issue writing a Haskell library for wasm and then having consumers compile their app leveraging your library (at which point it's bundled with the RTS)
- steveklabnik 8y ago
  I’m not sure what the serving part has to do with it; if I have a ruby library and a python library and I use them from a Haskell app, I’m getting three runtimes, regardless of if they’re bundled together or not.
  - whateveracct 8y ago
    Oh ok. So it's the same as native software exactly then. That's still nice!
deleted 8y ago
[deleted]

banachtarski 8y ago

The word "assembly" should have clued you in haha. And the "observation" applies to any natively compiled language, garbage collector or otherwise.

bayesian_horse 8y ago

There are plans to get garbage collection support into WASM, but GC is already possible, just not native. In my opinion the major benefit of WASM over Javascript is that it allows different runtimes to be used in browsers. Python for example has the pyodide project, which works quite well. But its download sizes are totally ridiculous. Which may not matter for certain applications, and even then, there should be a way to host and cache such runtimes for multiple applications or websites.

k__ 8y ago
They don't wanna "add GC" they wanna add the optiom to usethe GC of the host system, the JS runtime. Don't know how this will play with other languages.

fulafel 8y ago

GC code size can be pretty small. A mark & sweep GC is only a few kilobytes.