C# now beats Rust on WASM size

It's a bit of an unfair comparison, the benchmarked C# code here is also post-processed which none of the other targets are. See this comment[1] on reddit where the author announced this on the /r/dotnet subreddit, Rust can go much, much lower. The title is misleading at best and a lie at worst, this is great but saying it beats Rust is a far cry from the truth except for the very narrow benchmark made to showcase this tool.

[1]: https://www.reddit.com/r/dotnet/comments/1x7wsgb/rust_just_l...

There's something about C# that just feels so right for me for backends (as long as you stick to the more modern conventions).

Good tooling, modern language features (C# 15 has the long awaited unions, closed hierarchies), great debugging experience, etc.

> The 46.7 KiB program is the baseline, not the boundary.

what does this even mean

C# will slowly fade in relevance. Nowadays it gets picked mainly when the company already has a lot of .NET in place.

Worth pointing out this is not open source, if that is an important consideration when you're comparing the two (it is to me).

This is s bit of an unfair comparison, isn't it?

Since WASM ships with a garbage collector that C# can use while Rust does all the memory management itself, of course it will be bigger.

EDIT: Reading OP more thoroughly I think I'm wrong. Apparently in the compared versions, the C# version ships a runtime with garbage collector.

X is better than Y where Y is irrelevant and the difference is marginal is a low relevance observation.

this looks phenomenal. Can't wait to try it out.

Not very hard... Rust wasm binaries are ginormous.

If you care about WASM performance, size and memory usage, Zig is a much better candidate.

[dead]

Of course, they lobbied to transfer the bloat onto the WASM runtime itself

I never understood the appeal of wasm outside special performance cases. We never once considered moving from Blazor server side to the wasm mode. Not one time in 5+ years did it ever come up. The whole idea turned out to be a huge distracting waste of engineering talent. Instead of chasing this idealistic wasm pipeline and struggling with weird websocket transports, we could have been writing boring old cshtml and JavaScript on top of stateless HTTP.

Unless you are building a web version of autocad or premiere, I don't see the point of engaging with this technology.

Maybe I'm ignorant of some fundamental limitation here, but I cannot get excited for 47kB for a `print(42)`.