C# now beats Rust on WASM size
github.com78 points by sumnole 8 hours ago
78 points by sumnole 8 hours ago
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...
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.
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.
TFA did [0] the most important stuff for minimizing Rust binaries: release mode, LTO, strip, and abort on panic. But there is a lot more you can do if you really care about Rust binary size [1]: remove location details, purge the debug formatters, rebuild the standard library for size, abort with no error message at all, and nuttier stuff.
[0]: https://github.com/zion-sati/NetWasm/blob/main/docs/size-and...
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.
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.
If all possible metrics are considered, C# might be the best language ever created.
C# is an odd one. It's surprisingly flexible, but then oddly lacking in other areas. Quite productive, but also quite inconsistent and uncomposable.
Once you've tried a better type system (Rust), it's difficult to go back to C#. People jump through all kinds of hoops to get good performance out of it, and they're mostly able to.
Things I dearly miss from Rust when I'm using C#:
- Associated types in interfaces. (IEnumerable should not be forced to return a type-erased = heap allocated IEnumerator instance.)
- Move-only structs. (Currently, every type with value semantics is trivially copyable, even ref structs.)
I really like TS as well, but what kills it for me is the fragmented tooling landscape and tendency to bad practices by undisciplined devs (lack of explicit types making things hard to track down). I also hate writing intermediate schemas (zod, valibot, etc.) to get runtime type safety (love Typia for this). Debugger is flaky based on setup as well. I like writing TS solo, but hate doing it in a team environment.
> The 46.7 KiB program is the baseline, not the boundary.
what does this even mean
Slightly off topic it is just so bizarre how often Claude uses this turn of phase. It’s almost seems forced here. Anthropic has to be hard coding it to do this.
Worth pointing out this is not open source, if that is an important consideration when you're comparing the two (it is to me).
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?
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.
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.
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.
> 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.
> 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.
Is the support gap mostly related to weak references and finalizers? Or is something else missing?
(Obviously those are already pretty significant gaps.)
Those are supported afaics. It's reflection that isn't supported according to the docs.
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.
> 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.
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.
Of course, they lobbied to transfer the bloat onto the WASM runtime itself
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]