Hacker News Reader

Comment by highwaylights | Hacker News Reader

Very mixed feelings about this as there’s a strong case for the decisions made here but it also moves .NET further away from WASMGC, which makes using it in the client a complete non-starter for whole categories of web apps.

It’s a missed opportunity and I can’t help but feel that if the .NET team had gotten more involved in the proposals early on then C# in the browser could have been much more viable.

View on HN

Those changes affect the .NET runtime, designed for real computers. This does not preclude the existence of a special runtime designed for Wasm with WasmGC support.

The .NET team appears to be aware of WasmGC [0], and they have provided their remarks when WasmGC was being designed [1].

[0] https://github.com/dotnet/runtime/issues/94420

[1] https://github.com/WebAssembly/gc/issues/77

.NET was already incompatible with WASM GC from the start [1]. The changes in .NET 10 are nothing in comparison to those. AFAIK WASM GC was designed with only JavaScript in mind so that's what everyone is stuck with.

[1] https://github.com/dotnet/runtime/issues/94420

There's 2 things,

1: JavaScript _interoperability_ , ie same heap but incompatible objects (nobody is doing static JS)

2: Java, Schemes and many other GC derived languages ,etc have more "pure" GC models, C# traded some of it for practicality and that would've required some complications to the regular JS GC's.

A lot of the features here, stuff like escape analysis for methods etc. does not directly involve the GC - it reduces the amount of objects that go to the GC heap so the GC has less work to do in the first place.

How would this move .NET further away from WASMGC? This is a new GC for .NET, but doesn't add new things to the language that would make it harder to use WASMGC (nor easier).

For example, .NET has internal pointers which WASMGC's MVP can't handle. This doesn't change that so it's still a barrier to using WASMGC. At the same time, it isn't adding new language requirements that WASMGC doesn't handle - the changes are to the default GC system in .NET.

I agree it's disappointing that the .NET team wasn't able to get WASMGC's MVP to support what .NET needs. However, this change doesn't move .NET further away from WASMGC.

Webassembly taking off on the browser is wishful thinking.

There are a couple unicorns like Figma and that is it.

Performance is much better option with WebGPU compute, and not everyone hates JavaScript.

Whereas on the server it is basically a bunch of companies trying to replicate application servers, been there done that.

> Webassembly taking off on the browser is wishful thinking.

It has taken off in the browser. If you've ever used Google Sheets you've used WebAssembly.

Another niche use case.

Google Sheets is one of the most widely used applications on the planet. It's not niche.

Amazon switched their Prime Video app from JavaScript to WebAssembly for double the performance. Is streaming video a niche use case?

I think they meant most people aren’t building a high performance spreadsheet, not most people aren’t using a high performance spreadsheet.

> most people aren’t building a high performance spreadsheet

Lots of people are building Blazor applications:

https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

> not most people aren’t using a high performance spreadsheet

A spreadsheet making use of WebAssembly couldn't be deployed to the browser if WebAssembly hadn't taken off in browsers.

Practical realities contradict pjmlp's preconceptions.

Can you actually build something like Figma in Blazor? Does Blazor somehow facilitate that?

Don't mix mainstream adoption at the same level as regular JavaScrip and Typescript, with availability.

Microsoft would wish Blazor would take off like React and Angular, in reality it is seldom used outside .NET shops intranets in a way similar to WebForms.

> Blazor is seldom used outside .NET shops intranets

So, in other words, widely used in lots and lots of deployments.

Do you have a number for us?

I think that was sarcasm :)

I wouldn't be surprised if it did take off, classic Wasm semantics were horrible since you needed a lot of language support to even have simple cludges when referring to DOM objects via indices and extra lifeness checking.

WASM-GC will remove a lot of those and make quite a few languages possible as almost first-class DOM manipulating languages (there's still be cludges as the objects are opaque but they'll be far less bad since they can at least avoid external ID mappings and dual-GC systems that'll behave leakily like old IE ref-counts did).

All great and dandy, except tooling still sucks.

You still need to usually install plenty of moving pieces to produce a wasm file out of the "place language here", write boilerplate initialisation code, debugging is miserable, only for a few folks to avoid writing JavaScript.

I think you may be underestimating how many people really dislike JavaScript.

As many that dislike PHP, C, C++, yet here we are.

There will always be enthusiasts to take the initial steps, the question is if they have the taste to make it a coherent system that isn't horrible to use.

Counted out over N languages, we should see something decent land before long.

Reply on news.ycombinator.com