3 ms·

When a wasm runtime supports garbage collection and all the already proposed APIs it will be comparable to nodejs or JVM.

garganzol 3y ago
Let's hope that will never happen because it will lead to an imminent WASM death by making it opinionated. I would also suggest to officially separate WASM from any notion of API. So that any working group anywhere in the world could design whatever API they want/need - but it would not wreck the purity of WASM as a result. WASI/WASIX initiatives are good in that regard.
- brabel 3y ago
  WASM GC is already shipped with Chrome. Flutter is already compiling to WASM on the web and can execute with Chrome and apparently Firefox now, using the "native" GC instead of shipping one with the Dart runtime: https://docs.flutter.dev/platform-integration/web/wasm https://docs.flutter.dev/platform-integration/web/wasm EDIT : to clarify it, both Chrome and Firefox (nightly) require feature flags to enable WASM GC as of writing.
  - garganzol 3y ago
    What a perfect seppuku. RIP WASM, thou was fun while thou lasted. The only chance of survival is to declare WASM GC a heresy and to largely ignore it until it rots away like Intel iAPX 432 did. But considering the financial model of the current WASM development this plan may be unrealistic.
    - foota 3y ago
      Why? You can still implement a WASM runtime with no GC, and so it's just additional functionality for where's its desirable. Additionally, the GC spec is low level and allows for pluggable GC, and better defines the WASM memory model.
    - circuit10 3y ago
      Well there needs to be an alternative... A GC implemented in WASM isn't ideal because it doesn't let you walk the stack so you need to make a second software stack which is slow, and it also increases the binary size a lot
    - garganzol 3y ago
      @foota, WASM GC is a bad development because it's opinionated. For example, the nice WASM <-> CPU bijective mapping of capabilities is going to be lost. WASM GC now turns the WASM into something completely different, something in the rank of Java, .NET, Flash, Node JS, or Elang. For any GC to work, there must be a notion of a component model that defines the type system and the rules of type interactions. This is a complex topic by itself with myriads of decisions and compromises to make. This means that the end result won't suite everyone, if anyone at all. This will lead to WASM GC stagnation - it will be there but nobody will be using it because no one wants to loose the ground and compatibility with real CPUs. There may be some users like Dart or Flutter with their niche opinionated situations, but it's a drop in the ocean. As the time will pass, WASM GC will be gradually becoming a burden as it does not come for free - it requires maintenance, patches, security fixes. In the end, browser vendors may proclaim the WASM a new "Flash", "Java Applet", "ActiveX" that should be eliminated due to overdesigned complexity, too wide API surface, and associated security risks. Rinse and repeat, there is nothing new under the sun.
  - TUSF 3y ago
    Last I checked, the GC primitives in WASM are rather low level, and are more for building a GC system on top of, rather than relying on it to be your whole GC.
- ComputerGuru 3y ago
  As much as the broader programming world is loving WASM as a barebones VM and sandbox, it ultimately was created to further the interests of the organizations championing it and their desires and it's clear that making it a complete JS stand-in is the direction it is heading. GC is only a question of time.

garganzol 3y ago

Let's hope that will never happen because it will lead to an imminent WASM death by making it opinionated. I would also suggest to officially separate WASM from any notion of API. So that any working group anywhere in the world could design whatever API they want/need - but it would not wreck the purity of WASM as a result. WASI/WASIX initiatives are good in that regard.

brabel 3y ago
WASM GC is already shipped with Chrome. Flutter is already compiling to WASM on the web and can execute with Chrome and apparently Firefox now, using the "native" GC instead of shipping one with the Dart runtime: https://docs.flutter.dev/platform-integration/web/wasm https://docs.flutter.dev/platform-integration/web/wasm EDIT : to clarify it, both Chrome and Firefox (nightly) require feature flags to enable WASM GC as of writing.
- garganzol 3y ago
  What a perfect seppuku. RIP WASM, thou was fun while thou lasted. The only chance of survival is to declare WASM GC a heresy and to largely ignore it until it rots away like Intel iAPX 432 did. But considering the financial model of the current WASM development this plan may be unrealistic.
  - foota 3y ago
    Why? You can still implement a WASM runtime with no GC, and so it's just additional functionality for where's its desirable. Additionally, the GC spec is low level and allows for pluggable GC, and better defines the WASM memory model.
  - circuit10 3y ago
    Well there needs to be an alternative... A GC implemented in WASM isn't ideal because it doesn't let you walk the stack so you need to make a second software stack which is slow, and it also increases the binary size a lot
  - garganzol 3y ago
    @foota, WASM GC is a bad development because it's opinionated. For example, the nice WASM <-> CPU bijective mapping of capabilities is going to be lost. WASM GC now turns the WASM into something completely different, something in the rank of Java, .NET, Flash, Node JS, or Elang. For any GC to work, there must be a notion of a component model that defines the type system and the rules of type interactions. This is a complex topic by itself with myriads of decisions and compromises to make. This means that the end result won't suite everyone, if anyone at all. This will lead to WASM GC stagnation - it will be there but nobody will be using it because no one wants to loose the ground and compatibility with real CPUs. There may be some users like Dart or Flutter with their niche opinionated situations, but it's a drop in the ocean. As the time will pass, WASM GC will be gradually becoming a burden as it does not come for free - it requires maintenance, patches, security fixes. In the end, browser vendors may proclaim the WASM a new "Flash", "Java Applet", "ActiveX" that should be eliminated due to overdesigned complexity, too wide API surface, and associated security risks. Rinse and repeat, there is nothing new under the sun.
- TUSF 3y ago
  Last I checked, the GC primitives in WASM are rather low level, and are more for building a GC system on top of, rather than relying on it to be your whole GC.
ComputerGuru 3y ago
As much as the broader programming world is loving WASM as a barebones VM and sandbox, it ultimately was created to further the interests of the organizations championing it and their desires and it's clear that making it a complete JS stand-in is the direction it is heading. GC is only a question of time.