[skrtskrt]

My work experience is mostly python, so I hear "build a Django app"[1].

However Python and Ruby will hit scaling issues due to their performance limitations. 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.

[1] But don't use common Django patterns because they suck. Use it because of the completeness of the tooling and libraries.

[tstrimple]

> However Python and Ruby will hit scaling issues due to their performance limitations.

This is entirely determined by the problem domain it's being used for. The vast majority of web applications could use Django just fine without ever hitting a performance bottleneck outside the odd viral hug of death. You should prove you will have performance problems before you try to design solutions for it.

[skrtskrt]

True, I just noted that because if you're starting from true zero with no obvious preference for a particular language/framework, you have the opportunity to pick something that can reach a higher top end of performance before it requires fiddling.

[zerkten]

> 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.