Languages like Python and Ruby are just grossly inefficient. Single-threaded, huge memory profiles, and fully synchronous I/O. Whereas in C#, Tasks and async/await probably provide no shit 10-100x the performance in both compute and concurrency. It would probably be the same deal with Go or Java.

The point is, we tend to hand-wave these kind of choices away on HN. "Just ship it, language doesn't matter". But increasingly, I think it does. You want to make a product with an aggressive free tier, where only like 1% of the user base pays, or some data-heavy analytics thing, these kinds of decisions can be make or break for a business.

As far as language is concerned, Ruby and Ruby on Rails is the usual choice with Heroku and is marketed specifically towards RoR devs (https://www.heroku.com/ruby) and Postgres as db. Most startups who decide to go the RoR route are not going to decide to go with C# as far as the Microsoft ecosystem is concerned, which would be a different set of architecture design choices. If you wanted to market a more performant alternative Go would 100 percent be the way to do it.

I would still somewhat disagree with your conclusion that language choice is imperative though, so much as how well you architect your application and infrastructure. A simple RoR app that pulls in a bunch of static assets from an S3 bucket is going to scale at whatever load compared to an ETL tool like Airflow that might need to process terabytes of data on a daily basis and has to have more planning from the start.

My take is it’s great to use ec2 pricing, likely with beanstalk, and aurora or perhaps aurora serverless for sql. There’s room for moving fast with rails. Then as things grow, splitting off a microservice with the same url via your proxy server which uses go and redis. This way you are not over optimizing one data model before you know exactly what its schema is.