[SideburnsOfDoom]

More or less. any version of .NET >= 5 is cross-platform and is a direct descendant of the "Core" side of the fork, and so has no "full framework, windows only" variant.

It is "Core" in a lineage sense, but there's no need to make that distinction any more. The term "Core" is out of date, because the experimental "Core" fork succeeded, and became the mainstream.

[Kye]

I've been a long way from Windows development for a while, so missed that shift. I knew it was coming since moving functionality to the open source thing seemed to be Microsoft's target (with some skeptics doubting it, understandably). I didn't know it already happened.

[SideburnsOfDoom]

The shift is slow, but it has been ongoing for years, and is pretty much wrapping up now. .NET 5 was released in November, 2020 and that was the "beginning of the end" of the shift over.

For what I do, it's not really "Windows development" in any meaningful way. It is business functionality with HTTP, message queues etc, developed on mostly Windows laptops, and deployed to mostly Linux instances on the cloud. Not that the host OS is something that we have to think about often.

For this, .NET 3.x "the full framework windows only version" services are regarded as very much legacy, and I wouldn't go near one without a plan to migrate to a modern .NET version.

However, YMMV and people are also making windows desktop apps and everything else.

[Kye]

It sounds like .NET is on the way toward becoming the Java competitor it set out to be.

[SideburnsOfDoom]

Is Java on the way to being a .NET Competitor yet? I can't answer that, I don't know Java well enough.

I am told that the C# language has evolved faster and better than Java. Despite its origins in .NET 1.0 being basically a "Microsoft Java".

But paradoxically there is now more diversity of actively used languages that target the JVM. e.g. Kotlin, Scala, Clojure.

[Kye]

I got curious and found there's a whole wikipedia page for each:

https://en.wikipedia.org/wiki/List_of_CLI_languages

https://en.wikipedia.org/wiki/List_of_JVM_languages

Quantity of languages might be less important than: how many needs are served by those languages, whether the ecosystem is dynamic enough to keep expanding served niches, and whether the culture and community is likely to produce language support for a niche that matters to you ever or on a realistic timeline. The JVM does appear to have a lot more niches covered, but you can still do all the things those languages do in what's available for the CLI.

I don't know much about the current state of CLI and .NET beyond what I've read here, but it sounds like it's dynamic enough to keep expanding. I also don't know enough about the long tail of niche languages supported by each to know which direction they're headed.

That's the situation with the tools used for music production. In theory, any DAW (Digital Audio Workstation) can make any kind of music. In practice, they all move toward different kinds of music, and you'll run into increasing friction as you do weirder or more complex stuff if you pick the wrong DAW. Cubase can do electronic music, but you're better off with FL Studio or Live. Live and FL Studio can do orchestral, but you're better off with Cubase.

And I'd guess there's a similar dynamic with CLI and JVM and the languages that target them.

[toyg]

It has always been, but for 20 years Microsoft used it as a way to maintain lock-in at the OS level.

They've now abandoned that strategy, and instead they use it as a way to maintain lock-in at the IAAS/PAAS level (Azure).