[CharlieDigital]

C# is a language that serves many masters and if you trace the origin of its featureset, you can see why each was created. Take the `dynamic` keyword: created to support interfacing with COM interop easier[0].

It serves many audiences so it can feel like the language is a jack of all trades and master of none (because it is) and because it is largely backwards compatible over its 20+ years of existence.

That said, I think people make a mountain out of a molehill with respect to keyword sprawl. Depending on what you're building, you really only need to focus on the slice of the language and platform you're working with. If you don't want to use certain language features...just don't use them?

I think it excels in a few areas: web APIs and EF Core being possibly the best ORM out there. For me, it is "just right". Excellent platform tooling, very stable platform, very good performance, hot reload (good, but not perfect), easy to pick up the language if you already know TypeScript[1]; there are many reasons it is a good language and platform.

[0] https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...

[1] https://typescript-is-like-csharp.chrlschn.dev/

[WorldMaker]

> C# is a language that serves many masters and if you trace the origin of its featureset, you can see why each was created. Take the `dynamic` keyword: created to support interfacing with COM interop easier.

VB.NET's Object was created to support interfacing with COM interop easier. VB.NET's one key niche versus C# for many early years was COM interop through Object.

C#'s dynamic keyword was more directly added as a part of the DLR (Dynamic Language Runtime aka System.Dynamic) effort spurred by IronPython. It had the side benefit of making COM interop easier in C#, but the original purpose was better interop with IronPython, IronRuby, and any other DLR language. That's also why under the hood C#'s dynamic keyword supports a lot of DLR complexity/power. You can do a lot of really interesting things with `System.Dynamic.IDynamicMetaObjectProvider` [1]. The DLR's dependency on `System.Linq.Expressions` also points out to how much further in time the DLR was compared to VB.NET's Object which was "just" the VB7 rename of VB6 Variant originally (it did also pick up DLR support).

The DLR hasn't been invested into in a while, but it was really cool and a bit of an interesting "alternate universe" to still explore.

[0] https://learn.microsoft.com/en-us/dotnet/api/system.dynamic....

[DeathArrow]

>It serves many audiences so it can feel like the language is a jack of all trades and master of none (because it is)

That's why I like it so much. And now, I can write mostly functional code.

>I think it excels in a few areas: web APIs and EF Core being possibly the best ORM out there

It's awesome for web stuff and microservices.

[CharlieDigital]

    > It's awesome for web stuff and microservices.

The gRPC platform support is top notch and seamless and Aspire is just :chefs_kiss:

[mattgreenrocks]

I’m convinced the comment section hates multi-paradigm languages because you can misuse them. And it has features that may not be needed, which triggers this weird purist mentality of, “gee, it would be so much better if it didn’t have feature X.” But oftentimes that’s just pontification for its own sake, and they aren’t really interested in trying it out. Feature X remains something they won’t use, so it should go.

[gib444]

> EF Core being possibly the best ORM out there

Is it good at the wrong thing? Eg compare to strongly-typed query generators

[CharlieDigital]

It is a strongly-typed query generator?

[gib444]

I meant code generators like sqlc

[CharlieDigital]

Then this goes back to your question:

    > Is it good at the wrong thing?

No, it's good at the right thing which is allowing developers to write type-safe SQL queries using C# at the application layer versus writing SQL that gets translated into C#.

[mattgreenrocks]

Yep, up there with ActiveRecord as the finest ORM I’ve ever used. What seals it for me is the low coupling it imposes on entities.

[gib444]

I don't think you were aware of code gen SQL tools before this conversation right

[CharlieDigital]

What's the relevance here? Some sort of weird "Ha! Gotcha!" I'm certainly aware of code to SQL and SQL to code generators as generalized techniques, but I've not used SQL to code generators because these are not practical for most teams in the domain spaces where I operate.

Your original quote, verbatim:

    > Eg compare to strongly-typed query generators

"strongly-typed query generators" not "strongly-typed command generators" nor "strongly-typed code generators".

EF is precisely a code to structured query language (SQL) query generator and not a query to code generator.