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

	▲	xxs 2 hours ago \| parent [-]
		personally, I disregard and ignore cross-language benchmarks. Benchmarks are hard, benchmarks in managed languages are extra hard. And then the person writing the code has to be an expert in all languages involved to make it even half fair, instead of just a sound-bite/click-bait.

▲

weinzierl 3 hours ago | parent | prev | next [-]

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.

▲

afdbcreid 2 hours ago | parent [-]

C# doesn't (and can't) use WASM GC.

The comparison is unfair for other reasons (the C# runtime was optimized for WASM size and the Rust not, it's possible to be much smaller in Rust), but it's still cool.

▲

fweimer 18 minutes ago | parent | next [-]

Is the support gap mostly related to weak references and finalizers? Or is something else missing?

(Obviously those are already pretty significant gaps.)

▲

xnorswap 2 hours ago | parent | prev [-]

Any cross-language benchmarks are always unfair for those kinds of reasons, because ultimately everything is eventually possible against any given hardware.

What matters more for comparing what you get out of languages is the output of idiomatic code written against typical frameworks.

Indeed, it's still cool to see, even if it's optimised to beyond recognition, as seeing the occasional C# win is nice to keep the "re-write in rust" wolves from the door, who seem to ever lurk, especially in a world where re-writes appear easier.

▲

afdbcreid 2 hours ago | parent [-]

> ultimately everything is eventually possible against any given hardware.

Not everything, no. You can't run C# without the .NET runtime. Some parts of it are irreplaceable.

And the Rust optimizations to shrink binary size (see https://github.com/johnthagen/min-sized-rust) are commonly done in production when it matters, not just in WASM but also in embedded.

	▲	jeswin an hour ago \| parent \| next [-]
		> You can't run C# without the .NET runtime With NativeAOT, same a golang then. NativeAOT has worked wonderfully for us, and in some specific situations faster than Rust.
	▲	memsom an hour ago \| parent \| prev [-]
		> Not everything, no. You can't run C# without the .NET runtime You can compile C# to an AOT exe, and when you do that it will literally only be what it needs to work, less and dynamic libs.

▲

jedisct1 an hour ago | parent | prev | next [-]

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

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

▲

andsoitis 7 hours ago | parent | prev | next [-]

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

▲

bob1029 2 hours ago | parent | prev [-]

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.

	▲	bluegatty an hour ago \| parent \| next [-]
		It's for in-browser, security and portability, generally not worth it performance. A lot of edge cases they'd rather run WASM then a JS or Python VM, it has nicer containerization characteristics. But even with those key cases - it's not necessarily a core, critical technology. WASM is 'always on the horizon' as being important. If we had in 2015 what we had today, there might have been a bit of a breakthrough.
	▲	pjc50 30 minutes ago \| parent \| prev \| next [-]
		> Unless you are building a web version of autocad or premiere, Yes, but that's the use case. I don't think you'll be able to find someone respected saying "yes we should use this for all use cases regardless of what you're doing". At the other end, htmx is completely fine.
	▲	ChrisRR an hour ago \| parent \| prev [-]
		Because the abundance of javascript has made the web a bloated mess