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

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

[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?