> I just don't get why .NET is percieved as having a high learning curve

I feel like 99% of this is the historical perspective. If you dropped a totally new developer into a pure .NET 6 codebase w/ VS2022, I strongly suspect they would have a reasonable time of it.

IMO, senior developers who stopped following tech news are the primary reason the community has to struggle with this perception today. There are shops where legacy .NET Framework 4.x solutions are being spun up today for no reason other than ignorance has taken hold.

Arguably, the marketing disaster is still primarily Microsoft's fault, but I feel the community could do better with listening and adapting too.

> There are shops where legacy .NET Framework 4.x solutions are being spun up today for no reason other than ignorance has taken hold.

I wish! 2 years ago we visited one of our providers and I soon discovered their solution was being actively developed on .net 3.5 and Visual Studio 2008.

To this day I still have to install .net 3.5 on our machines that use their software (.net 3.5 isn't installed by default on Windows 10) so I know for a fact they didn't upgrade.

That's understandable - I've just very recently had the 'privilege' of fixing something in a .net 4.5 project - everything, from the tooling, the testing, the baroque xml project format felt super complex, Visual Studio-centric and a huge downgrade from what I'm used to nowadays.

Microsoft has a bizarre habit of overcomplicating every@&$1ing thing in their ecosystems.

I think because most of the features come out of customer request >> architecture plans.

As a result, you end up with a billion different weird behind-the-scene links and requirements that didn't have to be that way and consume unnecessary cognitive load when working with it.

> There are shops where legacy .NET Framework 4.x solutions are being spun up today for no reason other than ignorance has taken hold.

I’ve just about mentally broken down, unable to use the pattern matching features, among other features.

I think the basic problem boils down to this: poorly (or completely lacking) version and dependency references in external documentation.

That is, blogs, Stack Overflow, code examples, etc.

Most of that is the fault of authors, but presumably you don't want a 20 year .NET veteran to be the only person capable of writing a complete "Hello World"?

As a consequence, the new developer experience feels like the bad old Java days of "Oh, you want too foo? Well, that tutorial is built using the bar framework, which is incompatible with the nubar libraries you have on your machine."

Agree with another comment here that Microsoft needs to clearly cut legacy off + rename, in order to have a future.

This isn't remotely true. Any person that has learned for example C/C++ can be productive in a week of having picked up C#.

At the start you can just translate all the basic C constructs such as classes/structs/methods/for loops/ifs etc. to their C# version (which is extremely similar in nature).

After that you can add C# specifics such as LINQ etc, but it's not necessary to be proficient in the language.

Online snippets of anything you search for invariably just works, I've never had an issue of something being outdated.

I don't get where you're coming from: last week I upgraded a WPF .net 4.6 project (probably from 2017) to .net 6 without a glitch except of course the things I wanted to change (I moved all database calls to Dapper), while reopening a very simple Flutter project made in January this year I find a few deprecated things that needs to be corrected.

That's a weird perception - in my experience, .NET APIs have largely remained stable, at least when going back like half a decade. It's nothing compared to the node ecosystem, where yearly breaking changes are common, and looking at ta 5+ year old project, you'll see that the popular libraries for every problem used to be different.