Ask HN: How do you decide for a backend language?

In my freelancing career I usually choose the language with the following Q&A to my colleagues ( myself, if it's a side project ).

1. Are there business requirements for the language ( already written project, specs, etc. ) ?

2. What kind of budget does the company has for hiring devs ( killing point for Clojure, Elixir, TypeScript, etc. ) ?

3. What's the most difficult problem that needs to be solved by the product ( you probably don't want to create a 3D Game with NodeJS, right? Or a highly dynamic charting with PHP ) ?

4. Is there going to be a front-end / back-end division in the team ( Having a division makes you more comfortable in choosing the back-end language, since most full-stack devs are using NodeJS/PHP/Ruby ) ?

5. Finally if you are working on your own task and previous questions didn't give you the right answer, you could ask yourself : Do I need to learn something new or I want to build something fast?

At this point you will have eliminated most of the obvious choices. Recently I'm using Isomorphic TypeScript with NodeJS for most of my side-projects, but first thing I will do if something goes above a certain amount of users is to start thinking business-wise and answer those questions on my own.

Personally I feel most comfortable in Python / Go / Java - while I have no problem kicking off a project in another language, those three just happen to hit the sweet spot for me for different use cases while not getting too much in my way.

I assume we are talking about some side / hobby project, not starting new projects for a client?

One thing I usually take into consideration is if there are libraries or frameworks that will drastically reduce the amount of boilerplate I have to write.

Starting a web application in golang for example is surely possible, but while deciding on a router, template engine and datastore I can already start writing code in Django / Play / RoR.

If it is not an experiment to get to know a language or language specific features I usually prefer to go with some battle proven libs I can rely on and try to not reinvent the wheel.

Another thing to take into account is what kind of app you are actually going to build. Small CMS for a non profit? Crunching lots of numbers? CLI tool? Will you have to maintain it? Does it have to scale? How much time can you put into maintaining and scaling?

Those questions alone should already reduce the number of choices. For a simple CLI tool you could package a VM or require the user to rely on package manager and language which is installed on the system or you simply use a language that compiles to an executable.

So I guess my checklist in order I ask myself the questions: 1. Does one of my goto languages fit the project? 2. Are there libraries that would help me build it? 3. Which language of the remaining ones annoys me the least?

Now we're talking optimizing for a hugely multidimensional system here.

Expressiveness: If you've aiming for a large team, try to work with a language that enables large scale services and large teams - also in the long run, strongly typed languages will work out better for this case, Java / Scala being the obvious candidates. But if you go down a microservices route, other choices might work too.

Niche stars: Some languages have obvious strengths in certain niches, depending on what you want to build. Machine learning - Python, Microservices - Go, isomorphic JS web servers - Node.

Performance: Very many requests -> closer to the machine. Note that JITs have skewed this equation somehow towards being able to use scripting language, but it still generally stands, because if for some reason you can't track, code is falling out of the optimizer after a one line change, you're still screwed. Closer to the machine is more predictable.

Maturity / Current traction / Traction curve: Brand new is shiny and attracting bleeding-edge devs (making hiring easier), but be prepared to be the first one with a problem or having lots of devs around who love tech more than results and are gone for the next shiny thing in half a year. Lots of current traction is good, rather don't choose languages that are great but on the path down (Ruby). Be extra careful in choosing too exotic languages, you won't be the first company dying from not finding any devs for your ageing Groovy on Grails stack.

Availability: PHP and Java are safe bets, but it's much harder to separate the wheat from the chaff developerwise. Languages like Go or Clojure will find you more driven devs usually because they're not usually taught at university. Caveats: see above.

Lots and lots of other variables here, just some of the larger thinks to think about.

The thing is, most projects can be solved by most languages and frameworks. Apart from some special cases, there isn't usually that high of an impedance mismatch. This means that you have to look to other factors to decide... things like: * Tooling support * Talent pool / ability to hire * Available resources * Support / stability

FWIW, the last time I had to make this decision, I went with Python--a language I had never used before. No regrets.

* Golang for something CPU-bound, small apis that should be really really performant

* Elixir/Phoenix for mostly everything else, including REST APIs, regular web-apps, various chats, backends for games, mobile apps.

How? It should be easy and fast to write some functionality, easy to add functionality on late phases of development, it should be "secure by default" (e.g. autoescaping untrusted input, cross-site-scripting protection on by default), fast enough for your task (usually all the langs fast enough but 10x is 10x :) (rails vs phoenix)). You'd also want to check for specific requirements of your target architecture (e.g. processing video, websockets)