[JenrHywy]

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.

[jillesvangurp]

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.

[josephg]

> But at the price of having to include a heavy runtime; which bloats the binaries.

The other problem is that the "bring your own GC" model means if you use WASM in the browser, you end up having 2 garbage collectors for your program. And that makes sharing objects between javascript and the wasm bundle much more difficult & uglier. You essentially need to do manual memory management for any object thats shared across the wasm boundary to make sure its freed at the right time.

Having a unified GC means object references can be passed naturally from javascript to C# and back without any special code at the boundary.

[toyg]

> 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]

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, 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).

[jillesvangurp]

QT makes more sense with languages like C++ or languages that don't have their own UI frameworks. The whole point of running something like C# and Kotlin is using the frameworks common for those languages.

[fulafel]

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]

Sure, but I thought that a successfully implemented CG'd language running on WASM would have been something worth noting.

[antonvs]

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.

[fulafel]

That's true.

Besides Blazor, the WebAssembly Go port[1] does this as well.

[1] https://github.com/golang/go/wiki/WebAssembly

[jasonwatkinspdx]

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.

[flohofwoe]

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).

[kevingadd]

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

[baq]

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

[JenrHywy]

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]

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)