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

I imagine many people will say what you said, including me: For corporate projects I usually comply to whatever language the system is already written in and adapt to that

Assuming you're talking bout about a personal project, or a one-man startup...I'm interested in why you ask? That is, why do you doubt yourself? You've covered an impressive variety of languages; what keeps you from picking

a) What you are excited most about.

b) What you're most comfortable with, all things considered (years of experience, interaction with the community).

c) What the conventional wisdom says is good for the project that you have in mind, e.g. Rails for a full-featured web app, Elixir for something more minimalist with higher scalability, etc.

I don't have an ambition to deploy something into production, so I use Ruby for any quickie static sites, Python for data analysis (sans web-facing product), and am now redoing Past projects in Node because I've discovered that I enjoy ES6

1- Based on past experience

2- Scope of the project

3- Cost

4- Duration

If you just want to dabble with a bunch of languages pick whichever language is at the top of HN that week.

If you want to create good software then pick a language and stick with it for a decade so you really get to master it.

If you want to become a better programmer then work on interesting and difficult problems regardless of the language.

I started by learning what the company used; Java, PHP, Ruby, Bash, C. From there I picked up Javascript, Go, etc.

Personally, I pick the thing I'm most proficient in and enjoy building with. In a certain context certain languages make sense. Dynamic scripting can be useful for rapid development. Javascript is usually a must for frontend or simplifies code sharing longer term. Backend you usually need something more performant so after much searching I finally found Go to be a perfect fit but again thats a personal preference.

If working with a team I think it complicates things slightly. Now you must take everyone's skills and opinions into account. If working within a company you need to think about hiring and longevity of the code base. That's where normally you agree on 2-3 languages, again based on context and what's fit for purpose.

If you're just building something for yourself, go with what you're proficient in. If you want to learn a new language, pick one and build something to learn the language. If you're working with a team, democracy usually wins.

Hope that helps a little. Just my opinions and what I'm used to. Not gospel.

1. Which language you know the best.

2. How well this language is suitable for a given task.

3. If language you know the best is not suitable, pick second language you know best and repeat 1. and 2.

For example, you wouldn't really use Go to write big, but traditional web application. You'd use something like Ruby, Python or PHP (maybe Java too). So pick among these.

If the problem is programmer bound, I use Ruby / Rails. For CPU and memory bound problems, Go. For very JSON and HTML centric APIs (Elasticsearch, documents), or for those the involve executing JavaScript from untrusted sites (scraping), I use NodeJs.

Well it depends the nature of the project you're starting from scratch. If it's a new project at your employer, there could be factors like "how easy would be to hire / train people to work on this project in the future?" or "how mature this technology is / how likely is it that unknown problems will bite us in the ass in a few months or years". But if it's for personal use, I guess it's a matter of what your main motivations are for it. Personally, if I'm building an MVP or in other words, my main reason for building it is to get it in front of customers ASAP, I probably go with the stack I'm most familiar with. But other times I start a project just to play around, learn or get more familiar with a new stack, so then I do just that.

I use a language that I enjoy hacking. These happen to correspond to languages I understand very well in case I need extra features.

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.

For a personal project I usually prefer to get done with development as quick as possible so I choose the one which I am most comfortable with.

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?

Depends on a number of factors for me. If it's a small, well-defined project, just go with whatever you're happiest in. If it's a large project or a large company, then go with who you can hire (eg. Java, C#, etc.)

Actual language/subject matter practicality is a relatively minor consideration in comparison. You're usually talking about some sort of performance/dev-time/cost tradeoff and short developer time almost always wins. So small projects go with a quick happy language, big projects go with a "enterprise" language designed for large teams. Ultimately they're both about reducing the total devtime.

It's very rare for any particular task to be tightly coupled to a language. I can only really think of a couple, Erlang and SQL. Maybe C/C++ for high perf jobs. Otherwise, since all Turing-complete languages can technically do anything any other can, you're probably going to waste more time fiddling about in a new language that might be more appropriate, than if you just got cracking in your everyday general purpose language.

Most considerations beyond the above are probably just going to be people's personal opinions about their favourite language. It's like arguing emacs/vim or tabs/spaces, not going to help much ;)

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.

There are several things I might consider, but this is by no means an exhaustive list:

* Tech fit -- how does this technology solve the business problem? Have you considered how the overall architecture will look like? You might end up splitting them up to several different components each potentially valid to be written in different languages, depending on their nature. Given that, what do you need to achieve? Perhaps a Rails app is fit for purpose if you're writing a proof of concept. Or you might opt for a language that has established libraries for exposing a RESTful interface and write an SPA on top of that. My point is that it really depends on the business problem and how that is tackled.

* Ecosystem -- are there libraries out there that help you do what you need it to do? Will you have to roll your own?

* How will it be maintained? If you're not working for yourself, then you can assume your code will be maintained by someone else. Is the technology chosen accessible for your intended audience? Like you said, if it is a xyz shop, then it might make sense to write it in xyz. If it's a polyglot shop, then perhaps this is less of a consideration.

* What are the development tooling like? IMO this is quite important for my sanity because I dislike using clunky tools.

* How will the code be pushed out to production. Are there established best practices for pushing the code you're written in xys language into production?

* How easy is it to write tests for the language?

Something to also consider is whether it is good for the future. There is an element of YAGNI here, but it's worth considering the longevity of your technical choices and how easy it will be to upgrade.

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.

It's more about frameworks than languages.

You're already learning 2 languages a year. That's not so hard. The surrounding tech is the bigger investment.

* 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)

Scala is missing from your list, it has a wider adoption than Clojure and battle tested stack of frameworks/libraries such as Play, Akka, Slick, Spark just to name a few.

I have a personal rule, which I've shared on here before and people seem to think has some merit:

If a project is innovative in a business sense, then choose a boring technology. If it is boring in a business sense, then choose an interesting technology.

This is like asking a group of artisans what is the best kind of timber to make furniture out of, I'm afraid.

If it's a purely learning project for myself I would usually pick a new language which I would like to learn.

If it's not, you owe it to your client to have an open discussion about which backend (and frontend) language to select. If you are working with a contract, remember that you are only selling your services as a software engineer and that the client will eventually own the code (unless there is some other agreement).

For companies with existing technology stacks try to reuse existing knowledge (JNode, Java, .Net, ...).

For companies "starting from scratch": analyse possibilities and make a strategic decision about your technology then try to stay with it and build up the knowledge along the way...

In 1996 I made a decision to use Java everywhere where it is possible and I sticked to that decision up until today, so I prefer Java...

It depends on the requirements of the project, but generally speaking I'll write in whatever I feel I'll be most productive with (previously that was PHP, these days it's Node). This is because the code I write doesn't need to scale up - I write pretty niche things that will never have more than a few tens of thousands of users. The language choice won't ever lead to a performance problem because it'll never get so busy that the implementation is the bottleneck. If there's a problem it's most likely to be down to my code/logic.

If I had to write a scalable system where the code would make a difference for whatever reason, then I'd do a lot more research in to that specific area.

I choose languages based on what is best suited for the project. That is determined by the architecture of the project (is it a SPA or a more Ye Olde Fashioned web site? Is it just an API? Does it need web sockets? etc.)

The architecture is dependent on the requirements. Who will maintain this once I'm done writing it counts as a requirement. If I'm making it for someone else and I won't be maintaining it, and they don't have someone on hand to maintain it, I might not want to write it in Clojure or Node because it might be harder for them to find someone who can work on it affordably than if I write it in PHP or Ruby.

Sometimes multiple languages will be equally suited to the same type of project, in that case I go with personal preference. But that's very rare. Usually there's some good objective criteria like those listed above which will help you nail it down.