JVM's garbage collectors are at least a decade worth of effort ahead of CLR. I am talking out of my ass here, but from reading people working on large projects JVM has no problem chewing through multi-terabyte large heaps. The recently introduced collectors (Shenandoah and ZGC) even keep the same pause times (something like 99 percentile within 1 ms and 99.9 within 10 ms). The largest heap you might be able to use under CLR without ridiculous GC pauses and overhead is around 200 GB. Yes, value types and Span<T>/whatever lower the GC pressure, but not by a factor of 10×, and value types are coming soon™ anyway.

That's all of no use to me (I don't work on projects like that), but let's not just shove that aside.

I also don't really agree with this:

  > look and wait and do a half-assed implementation of a lot of tried-and-true C# language features some years later

Loom looks like a much more interesting approach compared to async/await hell (I've done it enough to know). I like records and upcoming "withers" much more than { get; set; } (which is easy to write but promotes shit code) because of their focus on immutability. (Yes, I am aware of { get; } and recently introduced { get; init; }, it doesn't really help with the thing withers are trying to solve — copying most fields while replacing one or two values, keeping both the old and the new value immutable). LINQ? maybe, I miss expression trees in Java.