Disregarding popularity, why should I switch to C#/dotnet from PHP/Go/Ruby?
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.
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.
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.
> advanced ORMs like EntityFramework and NHibernate
I've used all of these. Rails' ActiveRecord blows all of them clean out of the water.
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.
Ive seen so many awful queries with terrible performance out of EF.
LINQ is cool, and EF is alright if you have a decent team with good practices, but it takes a lot of discipline for it not to turn into a hot mess.
And for the record I hate LINQ to SQL.
(#(1 2 3 4 5 6) select:[:e | x isPrime]) collect: [:e | 2 * e]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.
- C# and F# are constantly updated in coherently. They have been on a yearly improvement cadence for the past 5 years.
- It's easy to pick up. I wrote 300+ samples for ASP.NET Core (https://github.com/dodyg/practical-aspnetcore)
- It's really a fun framework to develop in.
For all it's other features, I'm really not sure I'd call .net fast. It's got half decent speed, but it's not "woah that's fast"
> - C# and F# are constantly updated in coherently
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.
C# gets more features every year than F# because C# is still trying to catch up to F# 1.0. F# 5 got good updates this round (https://devblogs.microsoft.com/dotnet/f-5-update-for-august/)