Hacker News new | ask | show | jobs
by zerkten 2052 days ago
> I hear a lot of positivity on HN about what a single instance of C# monolith can handle, but I'm not familiar with the ecosystem.

I work a lot in the C# and .NET space, but also write quite a lot of Python. The performance differences come down to a few key things that are baked in:

* The .NET runtime (ignore the web framework for now) is highly optimized compared to the Python or Ruby interpreters. In practice, you can even save VM costs given how inefficient the interpreters can be. StackOverflow's original dev, Jeff Atwood, has written extensively about this over the years (https://www.google.com/search?q=c%23+asp.net+performance+sit....) For many web developers, you could consider runtime performance of the platform a solved problem. Obviously, there are situations where you still need to measure and optimize. If you have to optimize, some of the tools seem ugly, but work out well in practice (e.g. WinDbg and other low-level debugging tools which have existed for 15+ years.)

* The web framework options look like libraries compared to frameworks like Django or Rails. ASP.NET started with some sucky abstractions (I spent years elegantly working around these with custom HttpModules and HttpHandlers), but around 2007 they introduced ASP.NET MVC which was a big improvement. It is closer to Flask than Django, but there is some structure by default.

* Many C# developers are building on SQL Server. It has warts, but like the .NET runtime, it has some fairly serious optimization behind it - and, you have to buy into any bespoke SQL extensions as part of T-SQL. The tools available were always more advanced than those for open source database. In my experience, better .NET devs more frequently have intermediate and advanced SQL/RDBMS skills. As a result, they'll use ORMs, but catch things that I've seen missed in other frameworks. Dapper (https://github.com/StackExchange/Dapper) and other low-level tools are available for even better data access performance.

* Generally, the tooling is well optimized as long as you buy into Microsoft's workflows. With ASP.NET MVC and later, things improved a lot because the original tooling was built for the ASP.NET Web Forms abstraction.

All of the items above come together for great performance, but you have to be prepared to buy into the platform. This is becoming less of a challenge, but many people left .NET from 2006 to recently because of some enforced choices with the experience. I see a really good future with .NET Core because they've recognized and are fixing the earlier issues.