4 ms·

Admittedly I only scanned the article, but I didn't see any mention of C# or Blazor. I've only fiddled with it, but it seems that (when targeting WASM) Blazor l

Admittedly I only scanned the article, but I didn't see any mention of C# or Blazor. I've only fiddled with it, but it seems that (when targeting WASM) Blazor loads a (partial) .NET runtime in WASM and then happily lets your execute C# code - which seems in stark contrast to the article's claims about GC.

fulafel 3y ago
It doesn't claim DIY GC is impossible: The article first talks about difficulties a ship-your-own-GC faces, and enumerates workarounds for them (slide "GC and WebAssembly 1.0 (3)" and coupe of next ones). Then it starts talking about the planned GC support extension in WebAssembly and decides to go with that.
- JenrHywy 3y ago
  Sure, but I thought that a successfully implemented CG'd language running on WASM would have been something worth noting.
  - antonvs 3y ago
    Blazor isn't unique in that. At least some of the "non-mainstream" languages that the article mentions have WASM solutions. But, because they have to ship a non-trivial runtime as part of each app, they tend to suffer from the same kind of problems Blazor has, which is what the article was addressing.
  - deleted 3y ago
    [deleted]
  - fulafel 3y ago
    That's true. Besides Blazor, the WebAssembly Go port[1] does this as well. [1] https://github.com/golang/go/wiki/WebAssembly https://github.com/golang/go/wiki/WebAssembly
baq 3y ago
The article references browsers and JavaScript, so that’s the context. Nevertheless I found it quite interesting.
- JenrHywy 3y ago
  Maybe we read different articles? I thought the context was how it was hard to do GC in WASM currently, which is why we don't have many language choices. With that context, C# running on top of WASM seems pretty relevant?
  - flohofwoe 3y ago
    Garbage collected languages have been running in WASM for a long time already, but they had to "bring their own garbage collector" to run in WASM, which increases the size of the WASM blob. Garbage collection can now be delegated to the WASM runtime instead (e.g. see the short description here: https://chromestatus.com/feature/6062715726462976 https://chromestatus.com/feature/6062715726462976)
kevingadd 3y ago
DIY GC is definitely harder in WebAssembly than on most targets due to, among other problems, the lack of stack-walking
jillesvangurp 3y ago
That's so far the strategy. There are all sorts of garbage collected and interpreted things that run fine in wasm. But at the price of having to include a heavy runtime; which bloats the binaries. Not a showstopper for some things; like enterprise applications running in a fast network. But a bit of a blocker for normal websites. Firefox and Chrome actually have support for the new GC and threading support in wasm. That's behind a few feature flags. But e.g. Kotlin's new wasm compiler depends on that and manages to ship binaries that are quite small. That compiler is also being used for a new experimental target for compose multiplatform, which is based on Google's Android Jetpack Compose and extends it to other platforms (IOS, Desktop, and Web). Web now comes in two variants: html & kotlin/js and canvas + wasm. The latter renders using the same graphics libraries used on Android and IOS but compiled to wasm. None of this stuff is ready yet because the tooling and frameworks are pre-alpha quality and it requires feature flags to be set by the user. But, this is starting to look like a nice alternative stack to things like flutter and react native for cross mobile, desktop, and web development. The feature flags are likely coming off fairly soon. Safari is a bit behind. 2024 is going to be interesting. I'm guessing there will be a whole lot of activity around this in most commonly used languages and stacks.
- toyg 3y ago
  > The latter renders using the same graphics libraries used on Android and IOS That's annoying. I was hoping WASM would be a way to break out of the js/java/swift/ObjC stranglehold, not another baton to enforce such tyranny. It would be cool if they were targeting toolkits like QT instead.
  - flohofwoe 3y ago
    What does one have to do with the other though? You can use any programming language where the compiler supports WASM output, and any cross-platform graphics library that also has a (Web)GL or WebGPU backend. (also not sure how Qt fits in here, but it also has WASM support: https://www.qt.io/qt-examples-for-webassembly https://www.qt.io/qt-examples-for-webassembly, but IMHO Qt is way too bloated for this sort of thing) In the end, WASM running in browsers can only use browser features that are also available to Javascript, e.g. for rendering that would be canvas-2d, WebGL, WebGPU or the DOM). But at least WebGL and WebGPU are close enough to similar native 3D APIs that you can share some code between native ports and WASM running in browsers - but it still makes sense to use a higher level graphics libraries which abstracts over the 3D-API differences, or alternatively use wgpu.rs or libdawn in the native versions (which are the standalone native WebGPU libraries used by Firefox and Chrome).
flohofwoe 3y ago
Before WASM's GC feature was ready, it was basically "bring your own GC" which had to run entirely within the WASM context. With the new GC support in WASM, it's now possible to delegate garbage collection to the WASM runtime by exposing garbage-collected-references to the outside world (for instance in browsers that would be the JS engine garbage collector).
jasonwatkinspdx 3y ago
The article addressed that in some detail. There's a number of downsides to implementing your own GC atop the linear memory, due to limitations in threading model, modular security requirements, etc. Meanwhile the browser has a very high performance GC sitting right there we could expose to WASM fairly easily. That's the basic idea of current efforts and what the article/talk is about.

fulafel 3y ago

It doesn't claim DIY GC is impossible: The article first talks about difficulties a ship-your-own-GC faces, and enumerates workarounds for them (slide "GC and WebAssembly 1.0 (3)" and coupe of next ones). Then it starts talking about the planned GC support extension in WebAssembly and decides to go with that.

JenrHywy 3y ago
Sure, but I thought that a successfully implemented CG'd language running on WASM would have been something worth noting.
- antonvs 3y ago
  Blazor isn't unique in that. At least some of the "non-mainstream" languages that the article mentions have WASM solutions. But, because they have to ship a non-trivial runtime as part of each app, they tend to suffer from the same kind of problems Blazor has, which is what the article was addressing.
- deleted 3y ago
  [deleted]
- fulafel 3y ago
  That's true. Besides Blazor, the WebAssembly Go port[1] does this as well. [1] https://github.com/golang/go/wiki/WebAssembly https://github.com/golang/go/wiki/WebAssembly

baq 3y ago

The article references browsers and JavaScript, so that’s the context. Nevertheless I found it quite interesting.

JenrHywy 3y ago
Maybe we read different articles? I thought the context was how it was hard to do GC in WASM currently, which is why we don't have many language choices. With that context, C# running on top of WASM seems pretty relevant?
- flohofwoe 3y ago
  Garbage collected languages have been running in WASM for a long time already, but they had to "bring their own garbage collector" to run in WASM, which increases the size of the WASM blob. Garbage collection can now be delegated to the WASM runtime instead (e.g. see the short description here: https://chromestatus.com/feature/6062715726462976 https://chromestatus.com/feature/6062715726462976)

kevingadd 3y ago

DIY GC is definitely harder in WebAssembly than on most targets due to, among other problems, the lack of stack-walking

jillesvangurp 3y ago

That's so far the strategy. There are all sorts of garbage collected and interpreted things that run fine in wasm. But at the price of having to include a heavy runtime; which bloats the binaries. Not a showstopper for some things; like enterprise applications running in a fast network. But a bit of a blocker for normal websites. Firefox and Chrome actually have support for the new GC and threading support in wasm. That's behind a few feature flags. But e.g. Kotlin's new wasm compiler depends on that and manages to ship binaries that are quite small. That compiler is also being used for a new experimental target for compose multiplatform, which is based on Google's Android Jetpack Compose and extends it to other platforms (IOS, Desktop, and Web). Web now comes in two variants: html & kotlin/js and canvas + wasm. The latter renders using the same graphics libraries used on Android and IOS but compiled to wasm. None of this stuff is ready yet because the tooling and frameworks are pre-alpha quality and it requires feature flags to be set by the user. But, this is starting to look like a nice alternative stack to things like flutter and react native for cross mobile, desktop, and web development. The feature flags are likely coming off fairly soon. Safari is a bit behind. 2024 is going to be interesting. I'm guessing there will be a whole lot of activity around this in most commonly used languages and stacks.

toyg 3y ago
> The latter renders using the same graphics libraries used on Android and IOS That's annoying. I was hoping WASM would be a way to break out of the js/java/swift/ObjC stranglehold, not another baton to enforce such tyranny. It would be cool if they were targeting toolkits like QT instead.
- flohofwoe 3y ago
  What does one have to do with the other though? You can use any programming language where the compiler supports WASM output, and any cross-platform graphics library that also has a (Web)GL or WebGPU backend. (also not sure how Qt fits in here, but it also has WASM support: https://www.qt.io/qt-examples-for-webassembly https://www.qt.io/qt-examples-for-webassembly, but IMHO Qt is way too bloated for this sort of thing) In the end, WASM running in browsers can only use browser features that are also available to Javascript, e.g. for rendering that would be canvas-2d, WebGL, WebGPU or the DOM). But at least WebGL and WebGPU are close enough to similar native 3D APIs that you can share some code between native ports and WASM running in browsers - but it still makes sense to use a higher level graphics libraries which abstracts over the 3D-API differences, or alternatively use wgpu.rs or libdawn in the native versions (which are the standalone native WebGPU libraries used by Firefox and Chrome).

flohofwoe 3y ago

Before WASM's GC feature was ready, it was basically "bring your own GC" which had to run entirely within the WASM context. With the new GC support in WASM, it's now possible to delegate garbage collection to the WASM runtime by exposing garbage-collected-references to the outside world (for instance in browsers that would be the JS engine garbage collector).

jasonwatkinspdx 3y ago

The article addressed that in some detail. There's a number of downsides to implementing your own GC atop the linear memory, due to limitations in threading model, modular security requirements, etc. Meanwhile the browser has a very high performance GC sitting right there we could expose to WASM fairly easily. That's the basic idea of current efforts and what the article/talk is about.