
Ask HN: How do you decide for a backend language? - dvcrn
I&#x27;m &quot;only&quot; 6 years into my career but already worked with a dozen languages. While there are some obvious distinctions (like elixir being a better fit for concurrent systems or some being statically typed while some are not), most of them are very similar.<p>For corporate projects I usually comply to whatever language the system is already written in and adapt to that, but if I were to start a new project now, I wouldn&#x27;t be sure which language is the right choice.<p>Here are some of the languages I used for projects in the past:<p>- Go<p>- Clojure<p>- Elixir<p>- Ruby<p>- Python<p>- Java<p>- NodeJS<p>- PHP &#x2F; Hack<p>How are you deciding which language to pick when starting from scratch?<p>(On a similar note, the same thing could be asked for client side code: JS, TypeScript, ClojureScript, PureScript, ES6 &#x2F; Babel, Coffee, etc)
======
nl
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.

~~~
staunch
And if it's innovative in a technical sense, then choose innovative
technology. If it's merely innovative in a business sense, then it doesn't
matter what you choose.

~~~
eevilspock
> If it's merely innovative in a business sense, then it doesn't matter what
> you choose.

The point is focus. Pick one and innovate it extremely well.

------
drinchev
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.

~~~
acdha
The other factor I'd consider: is working on this project someone's full-time
primary job, part-time or shared by multiple people, or a one-time contract
gig?

A rapidly-evolving language / library ecosystem can be great if you work on it
full-time and have a lot of supporting infrastructure but miserable if you're
the person who was just told to patch a security hole flagged in the last
audit and you end up needing to upgrade dependencies with a dozen breaking API
changes just to install the version of something which the maintainers
officially support.

------
endymi0n
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.

~~~
mooreds
Curious why you think Ruby is on the way down?

(Just picked up 4 months of RoR experience after years of php and Java with
some dabbling in Python.)

~~~
cies
Some say it is slow, others like a more strongly typed language.

It might still have the most active web dev ecosystem of all languages; but it
has clearly shown its limits.

------
fallenhitokiri
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?

~~~
yarper
I also maintain a three pronged approach like this, where I keep one
dynamically typed scripting language, one compile-to-native speedy one and one
general purpose on a VM style language like Java.

Currently my picks are:

Rust -> to native + speedy Ruby -> nice relaxed scripting language Scala -> on
a VM general purpose language

Though the difference is more blurred from original intent these days - it
used to look like:

C Perl (5) Java / C#

which is considerably more pronounced.

The only addition I can make to this is I'd pick based on how I'm going to
deploy too - Java is fairly difficult to deploy to desktops compared to Golang
for example (for reasons like ensuring the correct JVM version is installed
etc). Ruby is even higher on the difficulty to deploy scale, to the point
where I probably wouldn't ship it to a customer non-dockerized (but if hosted
internally, that's fine).

------
nedsma
If you're starting a one man project, just take the one you're being the most
productive in. If the project is a team effort, then it comes down to the team
preferences or team members' willingness to change. From my experience, team
adopting a completely new language isn't the big deal per se, more difficult
is team dynamics, requirements/people changes, hiring new team members
especially if your area can't provide many people with desired skillset. Take
a look around what's the trend locally, for the vast majority of projects it's
more important to deliver a quality project on time, than to code in a, now
matter how, exotic (and other super attributes) language.

~~~
eddieroger
"Go with what you know." It even rhymes.

I'm all for learning stuff, and if I'm working on a project that has no
particular deadline (or a deadline that's far enough out that I can deal with
frustrations of learning), by all means use new and shiny. But if I have a
real goal and a deadline, I'm going to use something I already know in and out
so I can spend my time making, not learning. If I get something to production
and find that it's performance is horrendous, I can always come back and
optimize (or rewrite) later, but it's better to get something out and see if
it even works than to be fighting a new syntax or picking middleware.

~~~
nedsma
We're on the same page here. :thumbs-up:

------
lucasarruda
Start based on the project itself.

If it's a personal project and there are no risks involved, it's a change to
pick a new, innovative or trendy language, like Go, Elixir, Clojure, Rust,
etc.

If it's a personal project, but you want to complete it fast, probably pick
whatever you are more comfortable with. Don't try a new environment if you
have to deliver in time.

If it's a corporate project and chances you are not alone in that project,
pick whatever is more comfortable for the team. Don't try to innovate that
much or you have a chance of have a world of not predicted problems with that
language/environment.

But if it's a corporate project and you are mostly alone, then you could pick
a different language from that world. Some language that you have deeper
knowledge that others and maybe you wanted the team to try/adopt. And that's a
quite nice opportunity to both showcase you abilities, initiative and the
language itself - because companies generally have a hard time adopting new
things.

------
Ronsenshi
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.

------
adwf
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 ;)

------
manuelflara
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.

------
cies
For server and client side I'd go with a strongly typed language. This to help
me maintaining the code base, mainly by making refactoring cheap.

Server side they are: Haskell, OCaml (or Facebook's Reason), F#, Rust.

Client side: PureScript and Elm; and to a lesser extend: TypeScript and Flow.

Now what counts is maturity of the "web" ecosystem. For server side I think
Haskell and OCaml are more mature then F# and Rust in this regard. Client side
non of the contenders are _very_ mature, where TypeScript and Flow are more of
an extension on vanilla JS, so they will have good interop with existing libs.

For me Rust is a little too low-level for web dev, but it depends on the
performance characteristics you are looking for.

------
theli0nheart
My business is working with non-technical startup founders and helping them
get the technical side of the business off the ground. Your question is one I
(and my clients) ask myself all the time (I'll leave out my preferred stack
since it's not relevant to the question). Here are some questions you need to
ask yourself:

* Are you planning to grow the business if the app succeeds? If so, how hard will it be to find developers familiar with the stack you've chosen? Or how difficult will it be to train someone to learn it?

* What is the ecosystem like? Is it already large and active? Or is it large and languishing? Is it easy to find help on StackOverflow / Google if you run into an issue? How easy is it to configure it to run on a bare VPS / EC2 instance?

* How familiar are you with the stack personally, and what's your planned completion date? If you want to get something up and running fast, unfamiliarity will lengthen your timeline. If you don't care so much about spending extra time learning a new skill, then use whatever stack you are most excited about learning.

Ultimately--and I know this probably sounds unhelpful--this is really a "feel"
thing. Use whatever you feel the most comfortable with, whether that comfort
is existing knowledge of the language, or the comfort is knowing that you'll
be able to find help when you need it. Different things matter to different
people, so I can't quite tell you what to decide, but this has always worked
out for my technical decisions. Passion for your project can always overcome a
sloppy or bad technical decision.

------
augb
If you have not already done so, I would recommend choosing a language to
invest in, with the goal of becoming proficient in it. The purpose here is to
select a language to be your "default" language. Write out a list of the
things you value the most in a language and the things you wish to avoid.
Examine the languages/paradigms you have already learned. Do any of these meet
the criteria you listed (pros/cons)? If so, pick one of these to learn at a
deeper level. If none of these are satisfactory, spend some time researching
other languages or paradigms. Do other languages/paradigms match your criteria
more closely? If so, it may be worth investing the time to learn something
new.

I have yet to come across the "perfect" language or paradigm, but I have come
across ones that have stretched me to learn new concepts I likely would not
have learned otherwise.

One criteria I would _not_ leave off the list is this: "I want to enjoy
working with the language/paradigm."

------
danso
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

------
freek4iphone
I look at whether I need a quick prototype or a long term solution. I find it
is much quicker to hack a web based prototype in NodeJS as compared to Java.
Also, what kind of UI do we need, most of the times it's a web/javascript
based UI then the choice is NodeJS because of seamless data transfer using
JSON, other times the backend doesn't necessarily have to talk a lot with UI
like Batch jobs and I prefer Java. If I am going to need a lot of CPU
intensive jobs where manually spawning multiple threads can be beneficial I
would go for Java, NodeJS will not be very beneficial in that case. Other than
that it comes to features each language provides, like rich and robust
concurrent and collections library of Java. Similarly if a lot of data
analysis is required python is a clear choice of many, again because of the
rich data analysis libraries.

------
gizmo
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.

~~~
Adeohluwa
@gizmo is right, but u might prefer to learn from horrible experiences instead

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

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

I agree. I thought I had left this sort of topic behind at Quora.

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

~~~
eru
Go is reasonably performant (compared to slowpokes like eg Python or Ruby),
but not actually all that fast.

But that's probably fast enough for most projects, and seems to be fast enough
for you.

~~~
out_of_protocol
Basically on par with Java -JIT optimizations +less memory bloat, startup
speed. For even more performance something from C, C++, Rust league is
necessary

------
zwetan
I can propose another one: ActionScript 3 see:
[https://github.com/Corsaair/redtamarin](https://github.com/Corsaair/redtamarin)

So yeah I'm the author of this project and while when I started it, it was
mainly for fun "let's run AS3 on the command-line", couple of years ago I
started to force myself to use it more and more server-side in the spirit of
"eat your own dog food", and quite happy with it for my own side projects.

Now, as any other dev I also work with many others programming language
server-side, and on a project where I'm the one to make the choice about which
language to use I would say it does not matter much.

Seriously, most backend languages are more or less equivalent, except few
details or "religious faith", it's not like the features of one particular
language can make or break a project.

To chose one I pick the tech based on: who gonna maintain the project in the
long run ?, what other dev (team) or owner (company, vendor, etc.) expect ?,
what type of project or architecture is needed ? etc.

To be honest, being able to chose the language feels like a luxury, if you put
"religion" aside, some people must trust you will make the right choice, even
if you can chose whatever you want small comments like "we would like it to
work on a LAMP stack", "we are a Microsoft shop", etc. can influence the
choice.

But I do believe there is no wrong choice there.

~~~
ZenoArrow
RedTamarin does look like a great project, and I'm impressed by how much
effort you've clearly put into it.

I was just curious, what are your thoughts about Haxe? It's not quite the same
as AS3, but it is meant to be fairly similar.

[https://en.wikipedia.org/wiki/Haxe](https://en.wikipedia.org/wiki/Haxe)

[https://haxe.org/](https://haxe.org/)

~~~
zwetan
thank you :)

you got almost the answer here "It's not quite the same as AS3"

Haxe focus on transpilation/cross-compilation with its own language 'Haxe' and
its own compiler, libraries, VM, etc.

The closest to Redtamarin would be the NekoVM
[http://nekovm.org](http://nekovm.org)

I would say it is a different approach, Redtamarin focus on AS3 the language
but also on the AVM2 and by extension the reuse of the Flex SDK (for the
compiler) and other tooling that already exists (like Flash Builder IDE).

And so when you compare Haxe/NekoVM to AS3/AVM2 the difference mainly shine in
how you write programs and libraries.

Redtamarin approach is to provide a "C API" for low-level function and other
syscall, so dev can write "as fast as if they were writing AS3 as usual", they
only need to learn a new API and the subtleties of system programming.

You could find the same kind of differences with CrossBdrige
[https://github.com/adobe-flash/crossbridge](https://github.com/adobe-
flash/crossbridge)

Both NekoVM and CrossBridge focus (in their own way) on the reuse of C/C++
libraries, e.g. if you need zlib you can reuse it, but then it forces you to
compile native stuff.

Redtamarin almost opposite approach is to provide a kind of C standard library
(POSIX like even) in the context of AS3/AVM2, which allow you to port or write
the AS3 code to do native stuff in a cross-platform way, but you can not reuse
external native libs like zlib.

See for example this getaddrinfo sample code ported from C to AS3
[https://twitter.com/zwetan/status/752202410521726976](https://twitter.com/zwetan/status/752202410521726976)

The logic for that is let's say you need popen2.popen2() from Python, you can
implement it in AS3 reusing C functions like popen(), pipe(), fork(), dup2(),
close(), etc.

Except for fork(), the AS3 code will work under Linux / Mac OS X.

You could say that Redtamarin is a lot of hard work to add small native C
functions call, so dev can easily write AS3 programs for command-line and
server-side.

Another example, you can take JS (ECMAScript, ECMA-262) code, compile it and
run it with the redshell, I did it with the TypeScript compiler, I just needed
to implement ChakraHost, the detail is here
[https://discuss.as3lang.org/t/the-case-when-you-dont-want-
no...](https://discuss.as3lang.org/t/the-case-when-you-dont-want-node-js/307)

So to come back to Haxe/NekoVM, I'm not so sure you could either implement
popen2.popen2() with just the system libraries available or if you could just
compile/run TSC sources with Haxe/NekoVM unless making a big rewrite of the
whole thing.

Many people probably think that AS3 is dead because "flash is dead", but AS3
is also ES4 and so fully compatible with ECMA-262, being able to reuse IDE
with just a little swap of playerglobal.swc with redtamarin.swc and instantly
have syntax completion to write server-side program, publishing documentation
with tools like asdoc, etc.

All those things are the reason why Redtamarin focus on AS3 the language, and
why it is very different than Haxe and/or NekoVM.

~~~
ZenoArrow
Thank you for taking the time to write a detailed answer!

------
guhcampos
I always start with Python, because I can't find any other language to be just
as easy for others, including the "me of the future" to understand.

Then I go through Python's ups and downs for that specific project.

Is Python too slow for this? Then let's take a look at the most python-like
techs on the "fast as hell" list.

Does it need to be small/embedded? So let's look at the Pythonics of the the
crudest languages.

In recent years, this means almost anything I write is either Python or Go.

------
ams6110
Of the ones you listed, for backend I'd narrow to Python, Ruby, Java, or PHP.
Reason, they are mature and have a ton of libraries, frameworks, and projects
to build upon. They are not going anywhere.

For front end, it doesn't matter. It's a continually moving target. Your
front-end will be an endless work-in-progress, as the pace of browser change,
UI conventions/fads, and tech stacks shows no signs of slowing or converging
on a common solution.

------
yc-kraln
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.

------
kenkam
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.

------
chuhnk
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.

------
segmondy
I choose base on what type of project I'm working on.

If there is a legacy project/library that I need to work with, I just go with
whatever exists.

just a normal web application? \- ruby or php.

building for enterprise? \- whatever i feel like for jvm or .Net, but java or
c# for the SDK

heavy on rules? \- prolog

performance, small memory footprint \- go/c++/c

prototype, machine learning \- python

concurrency required \- erlang/elixir, java/clojure

------
aggieben
I usually decide based on some combination of a) do I know the
language/platform well b) is this for a client or for fun c) is this for
learning, and d) is this a mainstream platform, then (e) if not, then does it
have an advantage solving an important problem at hand?

If (b) for a client, then (a)/(d)/(e) are important. I know the .NET platform
best and it's a mainstream platform, so I tend toward that one. If your
strongest platform is X, then I think usually you should use X in general,
unless something else has a distinct advantage (i.e., write device drivers in
C or C++, not C#; use Y because it has libraries available that would save you
tons of work, etc).

If (b) for fun, then I pick whatever I feel like piddling around with.
Sometimes Node, Go, F#, C++, whatever.

If (c) for learning, then I pick something useful to me or something I need to
get better at. Right now this is F# and C++ for me, but will sometimes be
something esoteric.

------
flatline
Just use C++. C++11 is a nice, modern language. Lots of OO and functional
constructs. It compiles and runs just about anywhere. Lots of people know
enough to get stuff done with it. You don't have to worry about a VM and
performance issues, and with RAII and smart pointers you don't have to worry
overmuch about memory management.

------
onion2k
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.

------
sudhirj
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.

------
ceejay
I'd actually like to see more mixed shops. I proposed this once, but the idea
got shot down. This was at a time when we were having a very hard time
recruiting good developers for the technologies we were using.

IMO there's not enough difference between well-written Ruby / Python / PHP /
JavaScript etc. to make a big fuss about it.

It's pretty well documented / understood how one would decouple the backend by
simply interfacing your front end with a RESTful API backend.

That and the fact that it's become relatively clear to me that the present and
the future of the web is in rich client architecture.

------
chadcmulligan
tooling available and libraries / frameworks are as important as language
imho, often the domain of the application drives the choice of these. From
these the language is determined.

Other factors are familiarity and what tech the people who have to support it
are familiar with. Language is in some ways a less important choice and is
seldom a matter of choosing the 'best' one.

if you're talking about a side project though, knock yourself out. Personally
I'd recommend looking at Typescript (web), C# (windows), Swift (apple) or
Delphi (cross platform).

------
swalsh
I use the best tool for the job. If it is a quick scripting kind of thing,
python. An API, i'll probably use Ruby which has a gem for everything. If
there's a lot of complicated rules where I might refactor a bit, i'll use a
strongly typed language like C#. If its a data thing, keep it in sql. If its a
stats thing maybe R. If it's a hardware kind of thing, C++.

I don't really care about what's hot or trendy, I just want to accomplish the
goal, and i'll use the tool that gets me there fastest.

------
graycat
For a server-side language:

First, I decided to use Windows for my operating system. Why? Because when I
made the decision, my computing experience had been on IBM mainframes, super-
mini computers, PCs, and OS/2 with no Unix or Linux experience.

Second, on Windows I wanted a language that was a main Microsoft language with
their best integration with .NET, ADO.NET for access to SQL Server, ASP.NET
for access to the Microsoft IIS (their Web server software, _Internet
Information Server_ ), etc. I wanted Microsoft's best documentation.

For performance, I wanted a compiled language.

And I wanted a language with syntax and semantics that were _traditional_ and
easy to read, write, teach, and learn. I did want to avoid the deliberately
_idiosyncratic_ syntax of C also borrowed by C++ and C#.

I have no interest in _functional programming_.

So, I settled on the .NET version of Visual Basic .NET.

For the language, I'm just thrilled with it. For my startup, for the on-line
production code, I've typed in 80,000 lines of text with about 20,000
statements in Visual Basic .NET.

I find the language syntax and semantics easy to work with. The compiler is
nicely fast. I am not sure I have yet found a bug. How the language works with
IIS for developing Web sites is just terrific and, apparently, not commonly,
clearly explained.

Oh, and I use no IDE ( _integrated development environment_ , e.g., Visual
Studio) and, instead, just type into my favorite text editor and use some
command line scripts.

My main _beefs_ with Microsoft are (1) I wish the quality of the technical
writing in their documentation was much better and (2) I wish Windows was much
less vulnerable to computer _malware_.

But, for the question here, for a language, for me and my startup, it's Visual
Basic .NET. I'm thrilled with it.

For client side code:

I use just some simple, old version of HTML with a little, simple CSS. For my
Web pages, so far I have yet to write even a single line of JavaScript
although Microsoft's ASP.NET writes a little for me. From what I've seen of
more in client side programming in Web pages, I want as little as possible.

~~~
nanny
>idiosyncratic syntax

How is something like `Dim x as Integer` not idiosyncratic?

>syntax and semantics that were traditional

What's more traditional than C's syntax?

I'm not going to tell you that you shouldn't use VB, but those reasons are BS.

~~~
rescbr
> What's more traditional than C's syntax?

Not OP, but I see where he's coming from... He said his background is in IBM
mainframes/minicomputers. VB's syntax is closer to the languages those systems
commonly used, such as COBOL and RPG.

------
arc_of_descent
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).

------
BurningFrog
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.

------
markokrajnc
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...

------
Akashsharma
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.

------
tmaly
As some others have stated, if the problem domain is well understood, choose a
new language you have an interest in learning. If it is not, it is better to
stick with a language you already know. If you add a new technology to a
problem domain you do not understand, there is a higher probability that you
will create errors and headaches for yourself.

------
nikon
Personally I've agonised about whether X language has the best support,
community, performance and whether it's the cool thing right now.

But if you're starting a project and you're strong in a language/framework
already, just use that. Otherwise you'll spend months learning a whole new
ecosystem instead of building the damn thing!

------
alpeb
If pretty much the same things can be achieved with all these languages, then
the difference is not in the language itself but on other things like
community, learning curve, availability and price of devs. With that in mind I
would prefer Python or NodeJS.

------
verdverm
We are looking at Goa ([http://goa.design](http://goa.design)) because it's Go
and it generates a suite of extra tools and goodies. (API server, swagger
spec, JS client, Go client, CLI tool, tests, docs)

------
Gnarl
Choose a language that has robust exception handling and that enforces a
reasonable level of correctness at compile-time. Also, realize that checked
exceptions are your best friends, although you might not always be able to
handle them.

------
FollowSteph3
I say you're all wrong, the best language he/she should use is this:
[https://en.m.wikipedia.org/wiki/Brainfuck](https://en.m.wikipedia.org/wiki/Brainfuck)

------
eru
I am surprised I haven't seen HN's typical love for Haskell in this
discussion, yet.

(I do like it well enough, that I might even decide on my project on what I
can write in Haskell. People usually go the other way round.)

------
gregwagner
I usually pick Java for projects I know I'm going work with other since most
programmers know Java. If it's a solo project, I'll pick a language I want to
learn, so I can get some stick time with it.

------
sebastianconcpt
On the dynamic side of things I'm getting curious about Gemstone/S. Using
Smalltalk as backend would have a huge productivity impact.

On the static side, Swift in the backend might be interesting.

------
k__
First I look "which technology stack will suite the project best"

Then I remember that I'm bad at looking into the future and stick to "the
technology stack I know the best"

------
neverminder
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.

------
ed_blackburn
Inertia. Unless they're looking to extend a VB4 app without contemplating .NET
I generally go with what the client already has. Boring answer sorry.

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

------
xiaoma
For a growing number of applications, the correct answer is WordPress and
whatever plugins needed to turn it into what you need.

------
qaq
SPA that needs client side rendering -> node Need WS, soft realtime, HA ->
Elixir

------
ruslan_talpa
Maybe you don't need a language at all for the backend (PostgREST)

------
projectramo
I'm surprised you don't have a default language.

I just always pick Python.

------
pknerd
1- Based on past experience

2- Scope of the project

3- Cost

4- Duration

------
eggestad
First revel in the fact that you actually get to choose :-) most programmers
just get to play with a choice someone else made.

First of all, are you going to be the product owner, or is this a consulting
gig you're gonna walk away from? If the latter, chose what allow you do get
the job done for the least amount of hours. As your reputation grows for
getting the job done in few hours (cheap) you can increase your hourly rates.
You don't need to read on. Also, if you're sure that no bottle neck is going
happen. Meaning that the user will always get a response in less then 0.3
second, some thing. use whatever will get the job done fastest. In which case
you should be looking at what components (like Databases, search engines, etc)
are out there that allow you to get the job done fastest. Then choose you
poison according to those sub systems. There is an argument for easy
maintainability, in which case it comes down to how you tend to debug. I tend
to use debuggers a lot, and that leaves be with Java from the languages I know
from your list.

You need to identify the bottle neck your application is going to have. You're
rarely going to be wrong. I tend to operate with 5 bottle necks: CPU Memory
Disk Network IPC

CPU: Easy, won't happen. It requires that you've avoided a memory bottleneck,
meaning that you've figured out how to feed the CPU with data. There are only
three languages where this is really possible, C, C++, and Fortran.

Memory: Unusual for a backend project, but possible. Solving it requires that
you lay out your data the right way in memory, and you're again basically back
to C, C++, and (to a lesser degree) Fortran. Anything with a new operator and
garbage collector tend to be bad. If possible try finding an existing piece of
software to do the job for you, but it's rare.

For disk and network bottle necks, programming languages don't matter.

If disk bound you need to try picking a sub system that do proper caching for
you, like a SQL, NoSQL, or other system. Your design choice here will be on
what you base your language decision.

Since you say backend, I'm assuming that you're on a web or mobile app
frontend. In all likely hood, this is the bottle neck you're going to face.
You should be concerning yourself with the frontend to backend interactions,
not programing languages. Web frameworks and proper use of AJAX are more
important. Worrying about languages is like worrying about getting a Ford
model T, a Pinto, or a F-150 for a indy 500 or formula 1 race. You've asked
the wrong question.

IPC! Strictly not a bottle neck, but a problem that occur a lot. Remember that
a IPC call take about 1 000 000 times longer than a method or function call
within a program. You have to assume 40ms latency from the frontend to
backend. Calling web services, database requests within you backend if you
spread it over multiple servers have a 1-10ms latency. You can assume 5-10ms
in practice. Trying to keep a response time for a user interaction below 0.3s,
i.e 300ms you should realize that you have a tight budget for IPC calls. A
backend operation that involves 1000 DB requests is just not going to get done
in 300ms. If you know that your DB operations will be the bottle neck, avoid
ORM's like hibernate. You're going to be spending your time making DB
procedure and optimizing SQL. If you're going to have a lot of business logic,
chosing a language that don't lend itself to writing large programs may run
you into trouble. It's tend you to keep programs short and use IPC to call the
business logic. As a result I tend to stick to Java. Well, have been doing a
lot of C and C++ stuff earlier in my career, so I tend to be a little biased.
On the otherhand, have been wringing a lot of frontend logic in Javascript as
well, and detest the language.

Hope this helps.

------
ebbv
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.

