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 agree completely regarding libraries, C# has never had the "libraries for everything", especially open source ones. The better libraries have moved to ( or always have been ) licensed too which doesn't help that impression.

I'd like to hear more about your issue with the JIT and where do you find it a hindrance?

I've had a few benchmarks lately that performed better under JIT than AOT compilation, and while that isn't always the case, the JIT, especially on dotnet 10, performs very well.

> The problem I find is that no one writes C# libraries that actually do anything

Yes, because when you think about it, why should they?

MS has showed many times how unreliable and even user-hostile they can be, so the community at large is very wary of their ecosystem in spite of real advancements.

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.

That's probably the very reason it's arguably not the best language ever created. It has way too large surface area, getting close to C++ levels.

Sure, it's a valid language design, but it's also a negative in "understandability of each line of code", and thus maintainability, and even stuff like tooling, verification.

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.)

Nice, but still lacking proper generics (i.e. à la C++ templates) and typedef.

He was absolutely right to push back though.

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.

Is the support gap mostly related to weak references and finalizers? Or is something else missing?

(Obviously those are already pretty significant gaps.)

The models aren't writing new applications in C# unless you direct it to.