Several of the companies in our portfolio have gone through extended and often heated internal discussions about which programming language to use for backend development.  In these discussions I have encountered a bunch of arguments that I find myself disagreeing with based on experience.  I am presenting these generically even though they are often made with respect to particular languages. The point is that I disagree with the logic of the argument applied to any language.

1. NEW language has advantage x
   There is innovation in the language field, which is great.  And it’s true that there are always some new languages that have interesting capabilities.  But generally those are offset by lower stability (by which I don’t mean necessarily that any particular version will crash unexpectedly, although that can happen, but that new versions will come out more quickly), fewer available tools, and often a lack of libraries (if not library compatible with some existing language). There is also the risk of proprietary lock in, if the language is controlled by a vendor, or of finding oneself on a dead evolutionary branch.  For these reasons, in most cases choosing a new language as the primary development language in a startup amounts to too much innovation, which results in unnecessary compounding of risk.  The too much innovation issue also applies to most alternative (often experimental) implementations of more mature languages.
   

2. FOO language is motivating for developers and will help us attract talent
   This is often a specific instance of #1 above, but is also sometimes used as an argument between more mature languages.  Yes, some languages are more “hip” than others. But the primary motivation for developers (in startups anyhow) should be working on an innovative product/service and solving the problems involved in that. There is also another version of this argument which suggests that if you advertise for developers in an “easy” language you won’t get enough really talented folks.  That can readily be avoided by mentioning either no or multiple languages in ads and by having strong screens for candidates.
   

3. BAR is the only language we should use, so that we can more easily switch developers around
   It’s true that there is some overhead involved in using multiple languages, but I am wary of this one on three grounds.  First, if all you have is a hammer, everything looks like a thumb. Despite the fact that you can do almost anything in almost any language, there are differences that are meaningful with respect to specific problems (verbosity, completeness/quality of libraries, integration with OS, etc). Second, there is a problem if you are hiring developers that are not fluent in a few languages and can and want to pick up others.  Third, on the margin it is in fact motivating to experiment with new stuff.
   

4. EZ language is too slow
   Over the years this has become less and less true not just because of the advances in hardware and compiler/virtual machine technology, but also because most of the time we are not processing bound but data-access or communications bound.  And if you really had an issue with speed it would usually be confined to some fairly small critical portion of code, in which case you could always replace that bit with something faster.  There are some more nuanced versions of this argument, involving thread safety, global interpreter locks or garbage collection. All of these CAN matter, but are relevant only for a very small set of circumstances where they cannot be addressed by architecture or implementation changes.
   

5. BAZ language is more productive for developers
   This argument is often used in favor of scripting languages.  And yes, there are many instances in which initial productivity is higher with a scripting language (this is a strong reason to use multiple languages, see #3 above).  But with any system of meaningful size by far and away the largest determinant of developer productivity over time is the quality of the architecture and of the code base. I have noticed a few SaaS/PaaS providers touting proprietary languages with the productivity argument, but my response in #1 applies especially in those cases.

So which languages should startups work in? Originally, I was going to end this post with some concrete recommendations, but I believe those would distract from the original goal of dispelling some arguments that keep popping up.  Hopefully this will help make the language discussion at some startups shorter and less heated.