Go is still not good

C# is a highly underrated language that has evolved very quickly over the last decade into a nice mix of OOP and functional.

It's fast enough, easy enough (being very similar now to TypeScript), versatile enough, well-documented (so LLMs do a great job), broad and well-maintained first party libraries, and the team has over time really focused on improving terseness of the language (pattern matching and switch expressions are really one thing I miss a lot when switching between C# and TS).

EF Core is also easily one of the best ORMs: super mature, stable, well-documented, performant, easy to use, and expressive. Having been in the Node ecosystem for the past year, there's really no comparison for building fast with less papercuts (Prisma, Drizzle, etc. all abound with papercuts).

It's too bad that it seems that many folks I've chatted with have a bad taste from .NET Framework (legacy, Windows only) and may have previously worked in C# when it was Windows only and never gave it another look.

I'm still sad that Silverlight[0] (and Moonlight) died because people hated MS so viscerally back then.

It was actually really good for the time and lightyears ahead of whatever Flash was doing.

But people rather used all kinds of hacks to get Flash working on Linux and OSX rather than use Moonlight.

[0] https://en.wikipedia.org/wiki/Microsoft_Silverlight

While C# is great, but the problem with programming languages, is you're net only picking a language, but a kind of company who uses it, and a kind of person who writes it.

Which means if you write C#, you'll encounter a ton of devs who come from an enterprise, banking or govt background, who think doing a 4 layer enterprise architecture with DTOs and 5 line classes is the only way you can write a CRUD app, and the worst of all you'll se a ton of people who learned C# in college a decade ago and refuse to learn anything else.

EF is great, but most people use it because they don't have to learn SQL and databases.

Blazor is great, but most people use it because they don't want to learn Frontend dev, and JS frameworks.

I think you have a point with the types of resources, but in my experience, its also not hard to separate the wheat from the chaff with pretty simple heuristics (though that is likely very different now with AI and cheating!).

"Modern C#" (if we can differentiate that) has a lot of nice amenities for modeling like immutable `record` types and named tuples. I think where EF really shines is that it allows you to model the domain with persistence easily and then use DTOs purely as projections (which is how I use DTOs) into views (e.g. REST API endpoints).

I can't say for the broader ecosystem, but at least in my own use cases, EFC is primarily used for write scenarios and some basic read scenarios. But in almost all of my projects, I end up using CQRS with Dapper on the read side for more complex queries. So I don't think that it's people avoiding SQL; rather it's teams focused on productivity first.

WRT to Blazor, I would not recommend it in place of JS except for internal tooling (tried it at one startup and switched to Vue + Vite). But to be fair, modern FE development in JS is an absolute cluster of complexity.

I love C#, but have actually found LLMs to be quite bad a producing idiomatic code because the language is changing so fast and often they don't even know about the latest language(/blazor) features. I constantly have to undo my initial prompt and rewrite it to tell them that we don't use Startup.cs any more, only Program.cs, and Program.cs is a flat file and not a class.

I was so glad it died. It was a weird proprietary replacement for Flash, which itself was weird and proprietary, except the new one was owned by a huge company that publicly stated they wanted to crush Linux and friends.

A big chunk of their strategy at the time was around how to completely own the web. I celebrated every time their attempts failed.

I think that can be solved with an `instructions.md` and explicitly stating the language version/features to use.

As someone who developed in it at the time I found the reason it died was because they made new, slightly incompatible, versions every new Windows release.

After a while people got tired of doing updates.

C# is also the lingua Franca of mobile games because of Unity.

And when the front end is C# so is the back end.

Imo, Unity C# is almost 'not real' C#, as in it uses a completely different programming model, with different object lifetimes, programming and object models. I know the execution bits are the same, but programming for Unity feels very different in every way than writing ASP.NET code (and more different than moving from ASP.NET to Spring Boot)