Ask HN: How do you decide for a backend language? | Hacker News Reader

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

98 pointsdvcrn92 comments

I'm "only" 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.

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't be sure which language is the right choice.

Here are some of the languages I used for projects in the past:

- Go

- Clojure

- Elixir

- Ruby

- Python

- Java

- NodeJS

- PHP / Hack

How are you deciding which language to pick when starting from scratch?

(On a similar note, the same thing could be asked for client side code: JS, TypeScript, ClojureScript, PureScript, ES6 / Babel, Coffee, etc)

View on HN

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 similar to Intel's Tick-Tock model, where they alternate between innovating on technology or innovating on architecture.

https://www-ssl.intel.com/content/www/us/en/silicon-innovati...

Ohh so you're the guy who's responsible for writing the BI data aggregator with React... ;)

woah there, he said _interesting_ technology!

BI Data aggregators aren't innovative? ;)

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.

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

This is actually close to the opposite of my rule.

Don't you think that in some cases the innovative technology is what enables the innovative business?

I hesitate to give examples because every time I call out something as innovative, people are going to say "Are you kidding? Alan Kay was doing that in the 1700s! Charles Babbage invented object oriented functional noSQL whatevers!"

That would be an exception to the rule, sure, but bear in mind that if you're trying to innovate in both technology and business at the same time, that's a bigger leap than just one or the other, so the risks are going to be higher and it will probably take longer to get right. In other words, by all means do a project like that - but don't try to do it on a tight schedule.

Can you flesh out the reasoning behind the rule?

Taking some risk has benefits in innovation if you can afford it, but the project shouldn't have two major unkowns that can wildly affect its result.

In addition to that, parent's advice is also crucial for the team's motivation.

If the project is boring and you choose a boring tech stack to go, the team morale will only be harder to keep up as the time flies by.

This is probably the most important reason. Programmers love challenges. Keeping it interesting/challenging will also keep your good developers from looking for other jobs.

I'm going to tweet this. Upvoted.

this is actually interesting advice. I never thought of it like this.

Thats a very good advice for a lot of valid reasons and I follow the same mantra.

Well, put. I am borrowing it.

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.

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.

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

To me it looks like right now it would be easier to hire elixir devs than for instance ruby devs, lots of people are happy where they are but would jump ship in order to work with a new/interesting technology

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.

> you won't be the first company dying from not finding any devs for your ageing Groovy on Grails stack

That's intentional on the part of the managers of those two products. When they were boosting the presence of Groovy and Grails in Java shops, they were increasing the complexity of their products. They're now cashing in by supplying consulting and conferences at tight market rates.

The lesson here is to check out whether the backers of the language have technical chops, or if they're merely business people.

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

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.

Because it's no longer the cool kid on the block.

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?

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

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.

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

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

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.

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.

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

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.

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.

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.

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

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

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.

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.

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

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

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

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

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.

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

I can propose another one: ActionScript 3 see: 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.

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://haxe.org/

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

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

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

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

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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

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

"BS"? Ah, religious language wars again?

To me traditional means more like Algol, Fortran, PL/I, the original Basic, and maybe some more.

To me, the Visual Basic .NET (VB) Dim is, right, a bit obscure for now but, of course, back in the original Basic abbreviated Dimension for specifying bounds in arrays and was plenty clear. Microsoft may still be laughing at deciding to use Dim in VB. I regard Dim as a small mistake.

Finally to me, the VB Dim is like the PL/I Declare or the Fortran Real, Integer, Logical, Character.

For declaring (don't know a better term) in C, I can't gripe with just

int i;

IIRC that the syntax of C is idiosyncratic actually is somewhere in Kernighan and Ritchie.

In the example in Kernighan and Ritchie with declaring functions, the arguments, the return values, pointers to functions, etc., I couldn't get through the syntax. I'm sure there are a lot of C function declarations I couldn't proof read. Maybe if I worked and worked and ran a lot of test cases, I could understand it -- I'd also forget it by next week.

For loops I see Fortran's

Do i = 1, 10

as okay. The PL/I loops I like much better. In total what VB .NET has in loops is better still. The C loop syntax I don't like.

C wants to make a lot of use of their ++ idea, and I don't like it -- it's too sparse for me. One old excuse was that on some DEC computer being used at Bell Labs, there was an instruction for ++. I'm not impressed; to me, the most important reader of the code is me, not the processor!

Then where C permits

++i+++++j++

which officially in the language it does, I just gave up. Actually, when I tried that statement, two different C compilers gave different results. So, the C compiler writers can't understand the semantics of such syntax either.

I don't want to write, read, teach, debug, or bet my business on code with such syntax.

I've written some C, and I'll write some more if I have to, but I don't have to like it.

With C, having some syntax that is tricky to read seems too close to an actual objective.

It may be that some programmers regard VB as not manly enough. To me, VB is Microsoft's best language for applications programming and the code of my startup.

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

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.

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

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.

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.

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!

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.

We are looking at Goa (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)

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.

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

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

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.

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.

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"

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.

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.

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

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

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

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

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

I just always pick Python.

1- Based on past experience

2- Scope of the project

3- Cost

4- Duration

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.

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.

Reply on news.ycombinator.com