because of my own work history and experience, when I see this I hear "build a Rails app". but I am curious, what do other people that agree with this feel like is their go-to for something like that?
There are several stacks like spring-boot (no Hibernate), flask-sqlalchemy, elixir-phoenix that fit the description the parent has given. All these are pragmatic choices.
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.
> 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.
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.
> 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.
Any stack really if you have a well-gelled team that knows how to communicate and collaborate well together. If you don't have that as your starting point, things will be hard.
Rails is great for certain types of web applications because of the fast feedback loop.
With that said, there are many other good stacks out there today that allow you to go fast. I think Rails is really a victim of its own success. What DHH got right was to focus on developer UX. Now all the other major stacks have understood that there's a new normal in terms of minimum acceptable developer UX quality level and minimum feedback cycle speed. Spring Boot (possibly with Kotlin), .Net Core (possibly with F#), SwiftUI, Jetpack Compose, React Native, React, etc. etc. Everyone is building to the "sexy" dev experience that Rails introduced. jQuery and Prototype were a big deal when they first came out as well.
You also need a good CI/CD pipeline and modern DevOps practices so you can decouple deployment from release.
But like I said before, team communication above all else.