Ask HN: How do you choose languages for building applications?

Company / professional context:

Step 1: Raise your eyes above the computer monitor in front of you. What is the team / company already using? What will they likely be using in one year from now?

Step 2: Ask yourself honestly without "I wish I could and I wish I would" - can the problem be solved using the tech that the team / company already has invested in?

Step 3: Make decisions. Default to the answer in Step 1, but consider the evaluation in Step 2. Try to get as close to 1 as possible.

At home / "for the shits and giggles": Whatever is interesting. Sometimes even bending backwards to force functionality out of tech that has absolutely no business doing what I want it to do.

No matter what people say, the reality is that people use languages they know best. And unless you strive for the best possible performance, there is really no other reason to change that. Do not let perfectionism be in the way of "good enough".

Also, you can ship fast and write more performant version, possibly in different language, later.

Language choice isn't about religion, it's about leverage. Lisp-family languages like Clojure and Racket are at the zenith of expressive power. Elixir/Erlang is for telecom-grade fault tolerance, concurrency, and distribution. Rust and Go get you bare metal performance. If you're wanting to work professionally as a software engineer, you should pick a language based on future job alignment. And nobody "rewrites it later in a more performant language" that's just not a reality.

I have two metrics:

1) languages I know and like.

2) what are other things in the same area written in? This doesn’t mean those languages and libraries are best, but it does mean they will be well supported. Someone will update stuff to iOS 16, or when chrome changes how cookies work, or care when one of your users has 4 monitors all at different resolutions. If you pick something obscure enough, you are fixing all those things yourself.

All else being equal, what I've come to value more over time is long term stability of languages and their ecosystems:

- stable APIs of essential libraries and frameworks

- a grown up culture that accepts that something isn't dead just because it doesn't get an update 8 times a day

- tooling that will still work and be supported after 5 years (not a new package manager or build tool every year)

- communities and individuals around it that are focused on getting things done instead of status and drama

1. What’s vaguely appropriate. You’re probably not going to write C++ for browser frontend, and JavaScript is probably not a great choice for embedded. But there are a zillion equally valid options for web backends, for instance.

2. Ecosystem. I might choose a language for a game based on available frameworks. Or Python for ML based on available libraries. Or if you want to work with XMPP, Erlang is handy to know.

3. Familiarity. You’ll move faster and write better code with a language and ecosystem you and your team are already familiar with.

But often there are many valid options and you just have to choose one.

Depends on the situation

Work:

I prefer tech that is well known within the team that will maintain it. Keep the bus factor low.

Personal side projects:

It depends on my goal. Is the goal to learn a specific tech, or create a product? If my goal is a product, I choose tech that I know well. I want to focus on the product, and not spend time in google/chatgpt figuring out how to do X in Y. The product itself has so many unknowns, that I don't want to add more due to my choice of tech, otherwise I risk losing my motivation and the project ends up in limbo.

If I had to choose a single language for everything, it would be Java (or Kotlin if necessary). The eco system is solid and my productivity is easily 4x compared to other languages.

Most developers can learn to produce code in any language in days. But mastering a language and eco system takes years.

I work backwards from the outcome I want. I eliminate any languages that can't do whatever it is I'm building but that rarely has much impact; most languages can do most tasks. Then I consider cost and performance. Then I look at the effort it'll take to actually implement whatever it is (including learning or hiring for the given language.)

Then my teams ignore all that research and build it in the language they build everything in.

Simple — Rust for everything except Typescript for browser/mobile and Python for scripting.

Rust. I choose Rust. That's my language selection procedure.

What are you trying to accomplish? Say it's a start-up or a profitable business, you need to test your hypotheses, validate/invalidate the idea, etc. The risk is not technical, it's a business risk, so you ought to get to the truth as fast as possible, and you get there using what you're most productive in. The goal is to discover if it's "desirable, feasible, viable", not to optimize prematurely.

>Say, i want to build tcp client for check connection and can deploy anywhere without install any dependency

Why? What are you trying to accomplish? Where do these constraints come from? Where does the no dependency constraint come from? Where does deploying anywhere come from? Where does checking the connection come from? What is the real problem you are trying to solve?

These questions are to avoid the XY problem, to avoid the trap of solutionism, and to get to the "Job to Be Done".

Someone once asked me how to solder a thick copper wire to a thin steel plate. When I asked him why, I listened in disbelief as he answered that the fuse blew out and that he was going to get a thicker wire and solder it so it doesn't blow out. His solution comes from an incorrect diagnosis of the problem at hand, and he asked me about the solution framed as problem, not the true, root, problem.

To answer your question: it depends.

A mix of my own opinions and after reading comments on this post:

1. Your first choice should be the language you or your team knows best.

2. Every language is built to solve certain problems and are, at the end of the day, opinionated. This may not be true for the most popular generalist programming languages; but stuff like Purescript for example, is great if you already have a Haskell codebase, with Haskell developers and you need a frontend. Easy to onboard/get productive in vs learning React/hiring React devs.

Choosing the right tool for the job is imperative. I will not use Rust for my web UIs, I will not use Javascript for writing code on embedded devices. Research and decide accordingly based on how it fits your existing pattern of thought/time constraints/end-goals.

3. Avoid language zealots and maximalists. People who'll try their best to convince you to write and do everything in a single language. A lot of Rust people will attempt to write everything in the entire project in Rust, even stuff like web UIs. This creates unnecessary friction, and you end up fighting the language rather than being productive.

4. Have fun, learning a language expands your thought process, it exposes you to different ideas, ideas that you may bring into other languages. For example, after learning/working with Haskell I wrote my own small utilities for higher-kinded types in Typescript.

5. Languages are a tool, choose a tool that's right for the job depending on how long you have and how adept you are with your existing tools.

=-=-=

edit: anecdote

I was building a deeply nested tree representation of 3D models with thousands of meshes, materials, etc. I wanted to write the parser in Rust and do some fun parallelization, but I am simply not good enough with Rust atm to do so; therefore I've built a correct implementation of it in Typescript, something I know very well, and now I'll begin porting it to Rust while at the same time learning the language.

This does two things for me; my team can test my implementation and build on top of it since the API won't change, and I can take much less time re-writing it in rust while also learning about the language.

Just a little something I do when learning any new language; rewrite something I know very well in it. Be it Raytracing in a Weekend or one of my older projects.