AWS is cheap enough that "throw more hardware at the problem" is a viable option for most startups. So long as you're not being completely stupid with the way you've coded the first version, pretty much any language is going to work, and the cost of people who can code well in more esoteric languages that might be better suited to the problem domain are going to be increasingly expensive. Obviously there is a time to rebuild with technologies that scale better than what you started out with, but I doubt all that many startups ever actually get to that point.
AWS is not cheap. It's a rather expensive way to rent hardware. It's only "cheap" if you are using some aspect of elastic computing to use 100 machines for a couple hours.
I've worked with several startups who are paying 6 figure a month AWS bills. At that point it's really not a bad idea to take all those python or ruby data processing jobs and convert them to go. I have seen costs reduced by an order of magnitude this way.
The key point here is that some startups need a pretty decent scale before they have a MVP. How many useful search results could google have provided if they weren't crawling most of the web from day 1? Some social media or analytics startups need to process twitter's firehose feed, even when they don't have many customers.
I don't think you've ever calculated just how much that cost is.
Lets say that you have a web service that is serving 30,000 requests per second, with a 1 Kb request size and a 4 Kb response size and you're setting up an elastic load-balancer setup that on average keeps 300 c3.xlarge instances open.
Do the math and you'll find that the cost on AWS, considering the instances used and the bandwidth, is over $80,000 per month. And that's a conservative example, since by my calculations that's about $1,000,000 per year and I know companies paying much more than that.
Don't know what startups you're thinking about, but from where I'm standing, for startups that's a recipe for burning cash.
30,000 requests per second is 2,592,000,000 per day... That's quite a lot. Obviously we're not talking page views (because that'd be crazy successful and well beyond 'startup' territory), so we're presumably in the domain of data logging, analytics, social networking etc. Sure, AWS might not be appropriate for those. But then, the level of traffic you're talking about represents maybe 0.1% of startups. People doing "a CRUD app for a niche", which is most SaaS startups TBH, could run their software on 1 AWS medium instance for the first year or two quite happily.
You're right, we aren't talking about page views or CRUD, but it can happen in a B2B application.
I ended up working for a startup like that, so this was a real anecdotal example. Our stuff was built to run on the JVM and we managed to get away with a variable number of instances between 15 and 30 (at the time we used c1.medium, which are now deprecated) - AWS's ELB is great in such a scenario as it can be configured to bring up new instances in case of traffic spikes, or kill them in case they were unused. So for us, AWS was saving us money, however that's because we were very efficient.
My opinion is that if you're expecting your startup to grow soon (and I'm not talking about wishful thinking, but about requirements that have to happen for survival - i.e. you either get the desired contracts or you don't), then you have to prepare for it.
