[CharlieDigital]

I started my career doing ~20 years of C# from pretty much the very beginning (JavaScript even before then!).

Around 2020, I switched into the startup space and quickly picked up TypeScript since that's "what the kids use". It wasn't without struggles, but once I wrapped my head around TypeScript as "shapes for JavaScript", it clicked.

At the time, the startup was undertaking a new product built on Nest.js[0] which looked awfully similar to ASP.NET web APIs which had the benefit of being much more mature, complete, and with one of the best ORMs (EF Core). I suggested it to the team and was a bit shocked by the pushback.

It ultimately inspired me to do a bunch of writing [1][2] on just how similar these two languages are and how they've converged on syntax (no doubt owing to Anders at the helm). Of course, they ultimately still have quite a bit of a gap, but for teams that are working in TS and finding that they are outgrowing it, C# is a very natural choice.

I left that startup after a short stint, but boomeranged almost 3 years later. Company went from seed to series C in that time. End of last year, we started the migration from TypeScript on the backend to C# on the backend and haven't looked back. The toolchain is far simpler and stable, the "default" ORM is far more flexible and powerful, the more rigorous type chain seems more conducive for agent-driven coding. Team adapted relatively quickly within ~4 weeks.

[0] https://nestjs.com/

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

[2] https://itnext.io/getting-functional-with-c-6c74bf279616

[rafaelmn]

I can't say for sure because I don't know the full situation, but I've heard a similar story a few times and IMNSHO looking at it as "they made the wrong choice initially" is off because it assumes that a C# team could have delivered the initial version in the timeline required to get to the the next level of project.

If they had a team that knows nest and can iterate fast with it that's the perfect choice. I've worked at multiple agencies over the years and was mostly in C# teams. Whenever a C# team got on greenfield/startup projects it ended up being a shit-show of self inflicted slowdowns/over-complications. I've seen 3 projects where in large part due to slow development of the MVP the project missed investment window or ran out of funds.

From my experience Node/Rails teams were much more capable of delivering shit that works. It would eventually have a bunch of problems that would be non issues by default on a different stack like ASP.NET, but the difficulty of getting to that point and realizing that just being in that situation is a win is what most engineers miss.

[CharlieDigital]

    > ...because it assumes that a C# team could have delivered the initial version in the timeline required to get to the the next level of project.

I linked the Nest.js project because you can see how similar these two are[0] with Nest.js leaning into the OOP aspects of TS at the very core. Controllers and services are classes in Nest.js, for example. It uses a somehow more complicated DI system than ASP.NET. It is Spring Boot or ASP.NET, but without the maturity, performance, and ergonomics.

The team had developers that had done C# before and later hires also included former C# developers.

TS itself was new for the team at the time and several mistakes were made along the way resulting in a "dual-ORM" situation (Prisma + Drizzle; both with their faults) that ends up sapping a lot of productivity (one of the drivers to move to C#).

[0] https://typescript-is-like-csharp.chrlschn.dev/pages/interme...

[oaiey]

Hmmm. I have a different take there: when you are young and wild, you achieve stuff because you think later and instantly produce code. When you turn older, you do it the other way leading to your example.

In the early 2000s I have been in a startup and we delivered rapidly in C# as we did in PHP. We just coded the shit.

[ngruhn]

Same experience here. C# might have superior tooling, performance, whatever but the OOP baggage is too heavy. In theory you can write something else than a giant over-complicated, over-abstracted pile of OOP nonsense in C#, but every team I've seen has.

[hirvi74]

> the "default" ORM is far more flexible and powerful

I have never used any ORM that is as capable. Entity Framework Core with Linq is what keeps me on .NET.

[CharlieDigital]

Because EF's default behavior implements Unit of Work, a LOT of the complex transactional spaghetti ended up disappearing when we switched.

This aspect of EF is highly underrated for complex entity graph mutations.

EF makes the 90% use case easy and the 10% case possible with very little pain. The interceptors, global conventions, and other extension points are an enabler of complex behaviors that are still transparent to most of the team.

[wbobeirne]

I assume the startup wasn't also leveraging typescript heavily on the frontend, that tends to shift the weight in its favor. Having one set of tools to use across everything, being able to share logic and types without needing to go through lossy translation layers, and giving (especially small) teams better flexibility to move people around is a huge benefit.

[CharlieDigital]

We are using TS on the FE with React.

But the reality is that at some point, your FE and BE teams will diverge anyways and we use an OpenAPI spec as the contract (Nest.js, not Next.js).

So there was no benefit to using TS on both ends; only pain on the BE.

If a team is going to ship an OpenAPI spec and run it through a transformer, then it changes the selection criteria for a BE language:

    - Easy for a TS team to adopt; similar core semantics like `async/await`, exception handling, etc.
    - Flexible and pluggable OpenAPI spec generation for edge cases and advanced scenarios
    - Excellent ORM to improve productivity around CRUD
    - Good tooling
    - Extensive docs, platform maturity, but modern language features

C# meets all of those in ways that no other language and platform does.