[pas]

It's perfectly possible to separate the language changes from the mindless API/platform/ecosystem churn.

.NET Core finally considers Linux, the server OS, which brings it to parity with the JVM. Will this be the final rewrite? Who knows.

Plus there is a lot of churn in Java land too (new libraries, rewrites of old libs, streams, libs becoming unmaintained, etc.), just big corps don't ever do any real maintenance.

I would probably opt to use Scala or Typescript instead of C# anyway. And Rust if there's some performance critical part.

[pjmlp]

The big difference that many .NET Framework libraries won't work on .NET Core, and even less on Linux, because they depend on C++/CLI, Win32 interop or COM.

Then those corporations start to evaluate a rewrite to portable .NET Core and come to the conclusion that several third party components also don't work on .NET and they need to go shopping.

In the same process, they find out that said components actually have a perfectly working counterpart for Java since Java 1.4 or something.

And a new RFP goes out.

As for what to opt for, platform languages are always the best bet longterm.

As long as the platform is relevant on the market they stick around, guest languages come and go, and tend to be insignificant outside the platform where they have guest status as they have to reboot an whole new platform experience.

[pas]

Sorry, I worded my comment imprecisely. I meant the CRL and language feature developments can and should be looked at separately from the platform/ecosystem stuff.

I'm aware that Core is different, and that MS only ported a subset of their APIs, and thus many libs need to be completely rewitten, especially those that were already just wrappers/helpers for more Win32-specific things.

And this wrapping platform specific lower lever libs happens on other ecosystems too. Python users run into this quite a lot, Rust devs too, etc. And many early Java programs were basically platform specific, even if the JRE itself was not.