[whiskey14]

Can you please give a short summary of why I should give C#/.NET a go for my backend services?

I've been fighting battles in Python backend services to get a nicely decoupled API, logic and DB layers for a while...but sqlalchelmy, alembic and flask/django/fastAPI are my safety blankets

[electroly]

Other commenters have good specific points but I'll add one overarching theme: .NET is developed by a well-funded corporation that is incentivized to bring all the popular innovations from other ecosystems back to the .NET world in a cohesive form. If something becomes popular in another programming ecosystem and people want it, we'll get it in .NET and it'll be done in the same style as everything else we have. It's pretty refreshing working with a system that was designed to work together rather than cobbling bits together.

[dfee]

My journey went through mypy, then typescript for frontend, the typescript on node. The story here was the type system is so much better that it allowed better prototyping, larger codebases and confidence.

I’ve done a lot of C# and Java now over the last few years, and I don’t love their type system, esp compared to typescript, but they scale much better against large codebases - especially with tooling like bazel.

I’ve been looking at Haskell and Rust a lot to fill this intermediary: code that’s performant, with a very expressive type system.

I maintain(ed) a number of popular python packages, and that journey lasted for nearly a decade.

[daxfohl]

This is my experience, having gone the route you're looking. Haskell (~6 month trial) was unproductive for me. Primarily the ecosystem is full of abandonware. Secondarily it lures you into spending way too much time refactoring stuff into the most concise possible form, which you can no longer understand (and frequently needs rewritten completely because the tiniest change to the most concise possible form invariably explodes through several layers when you have to make changes later). Rust (~3 month trial) may be great for codebases where you'd legitimately consider C / C++, but too much work otherwise; I personally wasn't doing anything that I'd use C for, so it was not worth it.

I ended up being very happy with F# as a middle ground for several years, but eventually migrated back to C# as they started adding more and more F# features. The primary challenge with F# was the parity mismatch with the underlying runtime, so you end up having to write a fair amount of non-idiomatic F# to interop with common libraries. But otherwise it's great. (I also tried Scala for a year and hated it: too many ways to do any one thing).

[hakanderyal]

I was in the same boat. I wanted to switch a few years ago actually, but EF core was missing core features I took for granted in Sqlalchemy.

As for the reasons:

- Static typing and C# projects makes code organization and refactoring dead easy.

- Modern C# doesn’t require that much boilerplate, and has features that allows a developer to speed up development, like Python.

- EF Core covers everything I need from SqlAlchemy/Alembic.

- LINQ is an awesome way to work with collections. Type safe DB queries comes handy both when developing and refactoring.

- ASP.NET covers everything I need from flask/Fastapi.

- More speed and lower resource usage is nice.

- Being able to use an IDE with it’s full power is nice.

My main reason to switch was static typing, and my only requirement was a good ORM comparable to SqlAlchemy. The rest is just bonus.

[danuker]

> - More speed and lower resource usage is nice.

> - Being able to use an IDE with it’s full power is nice.

In my experience, Visual Studio is much slower when developing. My Python workflow affords a 200ms red-green-refactor loop, while VS is on the order of several seconds.

This might not seem like much, but it has a great impact on my engagement, flow, and satisfaction.

[hakanderyal]

Rebuilding the project to run the tests adds a bit of time, yes. I see this as a cost of the static typing, runtime speed etc.

It’s worth it in the end. YMMV.

[kcartlidge]

> Rebuilding the project to run the tests adds a bit of time, yes.

It costs money, but I've paid for NCrunch for a fair few years and find it invaluable for this reason. It doesn't even need you to save changes before it spots them and runs affected tests in the background.

If cost is an issue you can also start `dotnet watch test` going in a terminal/command prompt for non-interactive live-reload testing.

[danuker]

I am not so sure it's worth it. In general, developer time is much more valuable than machine time.

Maybe if you're building a large high-performance server, you should invest in performance. But otherwise, if you only look at at computational complexity, and batch up/avoid I/O when possible, you're fine.

[lowbloodsugar]

I grew up with BASIC and made it to Java by way of assembly, C, C++ and C#. This year I put some Rust into production tooling. I've used python along the way, but usually as a scripting tool. I've never worked at a company whose codebase involves a lot of python. So beware of confirmation bias in my thinking.

What follows is my opinion, I am aware it is my opinion, but in my sphere of influence, it is not up for debate when it comes to writing code. It might occasionally be a conversation over lunch.

I put python in the same bucket as BASIC. It's not a production language. "developer time is much more valuable than machine time." Yes. Absolutely. Iteration speed is vital. But it is vital in more than just the test loop. It is important in the "minor refactoring of various classes" up to the "major refactoring of entire systems" loop too. And python just doesn't make that easy. It actively makes it difficult. It makes comprehension difficult. It's difficult to look at python code in a code-review and have a good idea of what the classes involved are. I don't even write scripts in it any more. I've found that any script that is worth writing is likely to grow and evolve over time, and if it is not written in something like C# or Java, then it will become an intolerable mess. I've seen entire organizations that are basically cargo culting.

I encourage you to learn a statically typed language and its tooling.

[yCombLinks]

All of the benefits of static typing save a ton of developer time in other places. No one is talking about saving machine time as the primary benefit of static typing.

[gmueckl]

Static typing in .NET saves developer time on a massive scale. Sure, the compile times and startup times may be longer (and tests may take longer to run for that reason), but the languages also allow for editor/IDE tooling that boosts developer productivity massively. Visual Studio with Resharper or Rider may seem expensive, but if you work with these tools full time, they pay for their cost multiple times over in almost no time.

[hakanderyal]

For me, runtime performance is only a tiny percent of the advantages. It could have been slower than Python, I would still make the switch.

[roflyear]

This is true. Almost all C# projects will take a while for you to run. It is unfortunate.

The upside is hopefully you "don't need to run it as many times" but ... eh. No thanks.

[kcartlidge]

There is a delay, true. Inevitable with the compilation phase, and I do find it irritating that my Go stuff builds so much faster. That said, there's reasonable (not perfect) live reloading happening these days which helps somewhat.

[camdenreslink]

One reason is that entity framework is the best ORM out there. It blows sqlalchemy and alembic out of the water imo (I’ve used both a bunch).

Another reason is that decoupling and adding layers to your code is more part of the culture. Look up “domain driven design C#” or “onion architecture C#” and there will be a lot of resources on how to achieve it. There is stuff out there for Python as well (and the concepts translate between languages), but not nearly as much.

[mattgreenrocks]

The .NET ecosystem is great.

It feels a lot more professional than other ecosystems. For example, they actually talk about layering/coupling as professionals should! People actually seem to talk about architecture as well rather than blindly believing that the conventions forced on them by a framework are sufficient for all use cases.

I especially like the gradient in the .NET world from micro ORMs to full-fledged ORMS. Most ecosystems seem to develop a big ORM that constantly accrues features (and bugs) and eventually becomes enshrined as a "best practice" because it acts as a kitchen sink.

[daxfohl]

+1 I was much happier using Dapper compared to EF. I figure if it's good enough to run stackoverflow, it's probably good enough for whatever I happen to be doing.

The amount of open source in dotnet is great. (I think more than Java? My impression of that is dominated by Apache etc., though my experience in the Java ecosystem is limited. Presumably people in Java land would expect the same of dotnet being dominated by Microsoft, but that's really not the case).

[megaman821]

I haven't played with SQLAlchemy in a while, but I was comparing EF core to the Django ORM, and EF core seemed to be lacking in features. There were a few things missing but the two that pop to mind are Window function and Case statements.