Look, you want to poo-poo on WebAssembly, that's fine, but the folks who build these browsers don't seem to be concerned enough about having GC'd langs running on their platform. Who has more at stake - you or them?
Also, even when WebAssembly gets proper threading, .NET/Mono still uses a "suspend the world" GC mode which will still halt your execution.
Nobody is poo-poo'ing anything. It is what it is. .NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical.
> .NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical.
I guess I don't understand what kind of 'high-scale applications where performance is critical' wouldn't be suitable for .NET but instead better suited to a systems programming language like Rust. If the bottleneck becomes the single-threaded JS interop, then what difference does it make which WASM language/runtime you choose as long as it's at least as fast as JS?
Will it ever be as small as a systems language like Rust or C? No - never. But the productivity gains that C# & the .NET framework provide are a worthwhile tradeoff for 99% applications.
The .NET team is actively working to optimize the payload to a manageable size.
You haven't specified what evidence you're basing this statement on:
> ".NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical."
Because Javascript is a good fit? Facebook sends down 500k+ of JS and how many of their billion+ customers complain about it?
WebAssembly support for multithreading is in progress https://github.com/WebAssembly/design/issues/1073
Look, you want to poo-poo on WebAssembly, that's fine, but the folks who build these browsers don't seem to be concerned enough about having GC'd langs running on their platform. Who has more at stake - you or them?