Since we are still playing this game.

> Would this necessitate evaluation of Java 8's (and corresponding JVM) viability against modern languages and platforms too?

Contrary to .NET Framework versus .NET Core evolution, there are hardly any libraries for Java 8 that don't work in more recent versions (module based JVMs), or are available only in one specific OS.

Many business are stuck in Java 8 for reasons, or stuff like using Red-Hat Enterprise and not allowing any Java version other than the one shipped with the OS.

And there is the whole issue of keeping compatibility with Android, only supporting Java 11 (as of Android 12 - 13) and Java 17 (as of Android 12 - 14).

> .NET 6 is an LTS version and so is 8.

It is, that still doesn't make everyone run for them, specially when there are changes on how EF works or ASP.NET MVC setup code needs to be written.

Plus they still cannot handle Windows Forms and WPF properly, as the out of process designer is buggy and requires the likes to Telerik and Component One to rewrite their components for the new designer.

> It is true that situation with GUI frameworks in C# is far from ideal, it is being worked on, but there is no catching up to JS/TS front-ends written even for desktop applications. For all it's worth, Xamarin continues to be loved by enterprise, and, maybe, one day MAUI will be made successful despite extremely rough start (I'm not holding my breath though).

Xamarin has lost most of the enterprise love with the MAUI rewrite, if anything people are paying more attention to Flutter, when before we used to joke about Dart.

Besides pure Microsoft partner agencies, most polyglot consulting agencies never cared about Xamarin in first place.

Additionally most of the enteprise consulting gigs are now around Web and mobile Web.

> Almost all top participants in Techempower pretty much do some degree of benchmark gaming. However, this does not, by itself, indicate the deficiency of the language or the runtime (if it did, we'd have all popular languages classified as deficient). In fact, asm emitted for C# trades blows with the likes emitted for C++. In many-core gRPC scenarios, Kotlin is at a similar level of performance, but as a language itself does not allow going as low-level as C# does (it effectively competes with both Go and Kotlin, offering a different set of tradeoffs).

There is always FFI, C# also doesn't allow for many workloads where WinDev is keen to only let C++ play, like Windows shell, many of WinUI foundation pieces, or the new DevDashboard UI, no matter what the .NET team will do.

> Can you expand on this? F# ecosystem does see less developer activity than C# from the language standpoint. However, it receives all the same performance and shared library improvements, and .NET does not introduce changes which break F#. Similar to Sitecore statement, VM being targeted by a multitude of languages does not make it automatically better (or worse) nor is a proxy for its performance characteristics. It is necessary to assess a technology at its face value.

No tooling for GUI frameworks, no support for Blazor, not able to be part of Roslyn analysers, not able to take advantage of source generators (this breaks F# actually, as it cannot consume/produce such libs).

Sitecore isn't a language, it used to be the number 1 CMS product for the .NET ecosystem on big corporations, now they are leaving .NET behind, as they focus their portfolio in other developer stacks.

> NativeAOT was "done" for .NET 7 for win-x64, linux-x64 and linux-arm64 targets, with osx-arm64 (it was not a goal for .NET 7) pull-request narrowly missing the feature snap window, therefore getting postponed to .NET 8. It also appears the argument might stem from conclusions learned from GraalVM AOT which do not apply to .NET. Unless used in a serverless function, back-end .NET deployments are best served by simply staying with JIT, which would offer higher sustained throughput. Native AOT is first and foremost designed for completely different scenarios.

No it wasn't, as it only supported CLI and dynamic libraries, a very tiny set of use cases.

Likewise, the .NET 8 Native AOT still won't be able to handle all .NET Native scenarios, and Blazor AOT still relies on Mono AOT capabilities, with their own set of caveats.

Making excuses for what is supported or not, when there are competing technologies that can handle it better.

Well in polyglot agencies, it means the other competing technology gets chosen for project delivery, they aren't married to be handled as being "XYZ Developer".

> All code targeting .NET historically relied on features by definition incompatible with true AOT (like in C++). It is a non-trivial effort to address issues of specific frameworks, which is being done, and the language itself adopts newer features (source generation. unsafe accessors, linker/trimmer improvements) to make it easier.

Historically there have been endless versions of AOT compilation in .NET, including two C++ versions (Managed C++ and C++/CLI) able to mix native code with MSIL.

NGEN, Singularity Bartok (later adopted for Windows 8.x store), Midori Project N (later adopted for .NET Native), Mono AOT, CosmOS, Microsoft Research Phoenix.

> As for Linux, please give Avalonia a try.

If we ever get an RPF that actually cares about it.