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.
This is an entirely different toolchain from the official .NET one, which is kind of the point of the post. It 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.
That's because Blazor runs on top of Mono not .NET proper if you're using WASM for Blazor, but you can also do server-rendered Blazor and all of that becomes moot.
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.
I think the benchmark game was really useful. It wasn't a which is better, it was what are the tradeoffs. Some of that was provided subjectively by curating it into safe and portable vs hyperoptimized categories. But there is also memory footprint etc. It was also a gauge of which languages people who care about performance preferred, as those got rapid updates.
I love when C gets to use non standard freestanding extensions, Rust a no std, is game on, yet when other languages do similar approaches, it doesn't count, it isn't the same language.
I think part of the complaint has less to do with language toolchains/extensions and more that the post processing performed on the C# output via Binaryen is not unique to the toolchain. It's analogous to comparing the toolchain outputs while zipping one output but not the other.
I think it's also a bit unclear exactly what you mean when you list nonstandard C extensions alongside Rust's no_std and then say "similar approaches". Rust's no_std is part of the language proper so the commonality surely can't be the non-standard-ness of what is done to shrink binary sizes.
In both cases, you cannot simply take a random ISO C, ISO C++ or Rust crates code and hope it will work without a single code change in such environment.
IIRC no_std is a per-crate attribute and does not actually forbid use of std, so I think there's a decent chance you can use random Rust crates without changing them.
That being said, I do think it would have been nice if the author had chosen a more interesting benchmark, but alas...
[1]: https://www.reddit.com/r/dotnet/comments/1x7wsgb/rust_just_l...