Very fast, statically typed, clean language design with features like LINQ for data operations and fantastic async support, cross-platform, comprehensive standard library, advanced ORMs like EntityFramework and NHibernate, easy deployment including docker/self-contained/single-file, build anything from web/mobile/desktop apps, best-in-class IDE and tooling, Blazor UI component framework running .NET in the browser, solid gaming support with Unity, etc.
There's nothing quite like it, and I find myself coming back to it and doing everything faster. The only downside would be a smaller open-source ecosystem (for many various reasons) so you don't get all the "cool" libraries, although you there are more than enough to solve any problem.
I think the web front end could be a huge multiplier for them.
It's going to take a few years for Blazor to catch up & have a chance to surpass the Node ecosystem but they have a good shot.
They need more/better front-end specific tooling & a quicker feedback loop with hot reloading. There is some hope that hot reloading will make it in for next November's .NET 6 release.
As Wasm & Blazor improve, I think it has the potential to be what people like about TypeScript but with less setup required or worries about missing dependency support.
We're already building with Blazor using the server-side model and it's pretty incredible. We can get massive amounts of functionality built in minutes because it's just .NET, especially with all the existing backend logic easily shared and used by those components (via signalr).
The WASM mode is still a little rough but it's rapidly improving. Hot reloading will definitely make a big difference there when it arrives.
LINQ has nothing to do with ORMs, it's a generic querying/transform syntax that can operate on any kind of data structure, and it's expressiveness allows it to be seamlessly translated into SQL by EF and others.
Also it's hard to beat the static-typed nature of C#/EF and the fact that entities are just plain classes with no special needs or inheritance. They can be as "active" as you need them while the DbContext wraps everything nicely.
I'm dealing with some rather fun EF code inside triple nested for loops that runs several thousand queries before throwing a validation error. Now, I know that's the devs fault and not EF, but EF made it all just seem like harmless object oriented programming and not set operations.
I almost feel like I'd like EF for write operations, and Dapper for read operations. Strike a balance.
If its memory usage and execution speed are deal-breaking bottlenecks for you, then you're working at a scale few people actually work at. Here in the line-of-business web app electron mines, I get to optimize for developer productivity and simplicity.
I suspect you haven't yet seen tge power of LINQ, it's not the chaining that is its point - it's the lazy evaluation. It's not at all limited to DB operations.
Sounds like you've worked with poor code/developers. LINQ with EF translates into DB queries including aggreations and transformations. That's the whole point of compiling the query, unless someone either didn't understand the query they were writing or explicitly chose client-side evaluation.
Hello. LINQ isn't at all limited to LINQ-to-SQL. That is simply one of the numerous IQueryable providers, which is also possible to implement yourself by doing some expression parsing.
The ecosystem let's it down a little I reckon. I came over from the Java world and have dipped my toes into Rails and found the Java ecosystem far richer.
Though I do like it and think it's pretty good, it would really benefit from a bigger open source community. It's picking up, but it is on the backfoot due to starting out with a closed-source philosophy.
> By which you mean C# gets new features every year, and F# gets thrown enough tidbits to keep it looking alive?
Every new C# version makes interoperability more of a pain. The C# team have no interest in compatibility with F# and will NIH stuff that could've been taken from F# libraries. One of the biggest pain points for interop is tasks, for which there are half a dozen libraries for F# and everyone uses a different one. There's been an open issue for F# to have native task support for years, but progress is slow.
