Really? To me it was always a runtime VM done right! The .net CLR is much more stable, leak-proof, and performant in my experience. I have .net services that run on servers for years without ever being restarted.

Given that C# and "Rust" are neck and neck, I'd rather have a nice GC language to work with.

Go and C# are pretty much neck and neck until the batch size gets large. Rust is always ahead of C#.

C and Rust are really close, but if you look at latency C# is still lagging behind (Go performs way better in that regard).

Where did you see that? I've never come across that reputation before, only that the JVM has more usage (in high-perf scenarios) because it was cross-platform and had a bigger community.

.NET always had very good performance and the new .NET Core cross-platform framework and runtime is now consistently among the fastest in various performance benchmarks for all kinds of applications.

Oh man, yes they have. For a couple years now the CLR has surpassed the JVM in straight-line performance for many workloads. A lot of effort has been going into providing escape hatches without sharp edges for getting closer to the hardware with the likes of Span<T>, Vec, and the upcoming hardware intrinsics. It always started faster..

I’d guess (cause I’m lazy and don’t want to verify the code) that it’s because the CLR has much better unmanaged support. It’s a first class feature.

Indeed. It was designed to interact with C APIs directly from day 1 and they've made it more powerful fairly recently with Span<T> and Memory<T> (essentially "safe pointers").

You can literally develop entire applications in unsafe mode, with C's level of unsafety. Nobody does, but you could.

it has been around five years since that was even vaguely true