If one were to analyze this concretely instead of with a bunch of platitudes, you want to find the optimal intersection between the productivity a language gran

If one were to analyze this concretely instead of with a bunch of platitudes, you want to find the optimal intersection between the productivity a language grants you for the task you are trying to accomplish, the amount of developer time required to maintain it, and the hardware required to support it. 1) Productivity - The speed at which you can create a respectable prototype. This is not just a matter of your team having mastered the language -- some languages are more specialized than others. For example, it will be orders of a magnitude easier (i.e. will require less dev time) to build a distributed system in a language with built-in actor support (i.e. Go, Scala, Erlang, etc.) than it would be to do so in say, PHP. 2) Maintainability (in terms of dev time) - The languages and its predominant frameworks will dictate how difficult it is to maintain a codebase. For example, many programmers will attest that statically typed codebases are easier to grok and maintain than dynamically typed. Dynamically typed code requires more edge case testing, and statically typed code allows an entire class of bugs to be compiled at runtime. 3) Hardware - Languages have different performance characteristics. Some languages will require $x / unit of web traffic. Others will require $y / unit. This translates into the # of servers required to support your app, which may diverge at a polynomial rate or worse over time. This is unlikely to be a big factor in the early goings, but it can matter a lot when / if you achieve success, so can be a worthy tiebreaker -- because it is highly unlikely you will be switching languages entirely once your company is in the groove, so the choice you make early on will stay with your company for a lifetime.