"Best tool for the job" is not a knowable truth. Best for what time frame? For what shifting array of tasks?

Often we pick the tool that will be perfect for high performance or a known task, but if you're still figuring out the product, why not make an MVP using what you know? I rarely see anyone fail because they chose, say, PHP. <cough>Facebook</cough>

Good point. FB may be an existence proof that the utility/power of the language, at a certain point, is not necessarily the bottleneck in execution.

Can we say this? A startup is more likely to fail because it couldn't iterate fast enough than because it didn't start with a powerful enough platform/stack?

If so, then you should pick the platform/stack that lets you iterate the fastest. Consider both your experience and your problem space when making the choice...

Is that really the lesson to take away? They have lots of projects that are not in PHP and designed a superset of the language with features it didn't have and their own VM for it, among other things, so, while they may have overcome the issues, I'm not sure that it didn't matter.

this may be a great way to go about in hackathons where one has very less to loose and success is greatly rewarding. if nothing, at least you learn something new. contrarily, in a startup a lot of things are on bet - money, opportunity, time - or may even mean difference between success and failure. it all boils down to reward-risk tradeoff.