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.
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.
I'm very curious to hear when? Because even the people that argue managed languages can be faster than unmanaged, say it because the JIT has better information at runtime. But NativeAOT cannot be better (and will be worse) than LLVM with PGO.
some of these are consistent enough that there are workloads where PGO does worse than non-PGO.
they can all be fixed, of course. which is why what you said is true in the limit, but it might not be true for right now
Microsoft already has both dynamic PGO in .NET JIT and traditional PGO in its C++ toolchain, after all.
And for that matter, there's no reason LLVM itself couldn't eventually be a target for native AOT.
It already is implemented, I believe. The thing I wondered is how NativeAOT could be faster, which is what GP claimed.
(Also, practically it should be slower because NativeAOT is based on the JIT and the JIT is worse at optimizing than LLVM).
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.)