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.<p>[1]: <a href="https://www.reddit.com/r/dotnet/comments/1x7wsgb/rust_just_lost_the_classic_hello_world_wasm_size/ph93azh/" rel="nofollow">https://www.reddit.com/r/dotnet/comments/1x7wsgb/rust_just_l...</a>
This is an entirely different toolchain from the official .NET one, which is kind of the point of the post, which is experimental, but intended to for production, not for beating benchmarks.<p>Rust also builds a pretty small binary, which is cool. This isn't really meant to be a 'C# is better than Rust' post, but more pointing out that Blazor (which is the official MS implementation) builds huge binaries; often >10MB, which is a real problem. This fixes that.
personally, I disregard and ignore cross-language benchmarks. Benchmarks are hard, benchmarks in managed languages are extra hard.<p>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.
> The 46.7 KiB program is the baseline, not the boundary.<p>what does this even <i>mean</i>
There's something about C# that just feels so right for me for backends (as long as you stick to the more modern conventions).<p>Good tooling, modern language features (C# 15 has the long awaited unions, closed hierarchies), great debugging experience, etc.
Worth pointing out this is not open source, if that is an important consideration when you're comparing the two (it is to me).
Of course, they lobbied to transfer the bloat onto the WASM runtime itself
X is better than Y where Y is irrelevant and the difference is marginal is a low relevance observation.
This is s bit of an unfair comparison, isn't it?<p>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.<p>EDIT: Reading OP more thoroughly I think I'm wrong. Apparently in the compared versions, the C# version ships a runtime with garbage collector.
C# doesn't (and can't) use WASM GC.<p>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.<p>What matters more for comparing what you get out of languages is the output of idiomatic code written against typical frameworks.<p>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.<p>Not everything, no. You can't run C# without the .NET runtime. Some parts of it are irreplaceable.<p>And the Rust optimizations to shrink binary size (see <a href="https://github.com/johnthagen/min-sized-rust" rel="nofollow">https://github.com/johnthagen/min-sized-rust</a>) are commonly done in production when it matters, not just in WASM but also in embedded.
> Not everything, no. You can't run C# without the .NET runtime<p>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.
> You can't run C# without the .NET runtime<p>With NativeAOT, same a golang then. NativeAOT has worked wonderfully for us, and in some specific situations faster than Rust.
Is the support gap mostly related to weak references and finalizers? Or is something else missing?<p>(Obviously those are already pretty significant gaps.)
Not very hard... Rust wasm binaries are ginormous.<p>If you care about WASM performance, size and memory usage, Zig is a much better candidate.
this looks phenomenal. Can't wait to try it out.
[dead]
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.<p>Unless you are building a web version of autocad or premiere, I don't see the point of engaging with this technology.
> Unless you are building a web version of autocad or premiere,<p>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.
It's for in-browser, security and portability, generally not worth it performance.<p>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.<p>WASM is 'always on the horizon' as being important.<p>If we had in 2015 what we had today, there might have been a bit of a breakthrough.
Because the abundance of javascript has made the web a bloated mess