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.
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.
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.
> 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.
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.
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.
> 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.
[1]: https://www.reddit.com/r/dotnet/comments/1x7wsgb/rust_just_l...
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.
Good tooling, modern language features (C# 15 has the long awaited unions, closed hierarchies), great debugging experience, etc.
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.
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.
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.
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.
With NativeAOT, same a golang then. NativeAOT has worked wonderfully for us, and in some specific situations faster than Rust.
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.
(Obviously those are already pretty significant gaps.)
If you care about WASM performance, size and memory usage, Zig is a much better candidate.
Unless you are building a web version of autocad or premiere, I don't see the point of engaging with this technology.
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.
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.