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.

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.

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.

chose the one I am familiar with

Forwards and backwards stability. I want my language to be able to run code I write today in 2035. And for code I write in 2035 to work on my toolchain from today. I don't want code I've written to stop working or only work on eternal wave of newest and break on setups a few years old. I don't want to install a separate version of my language for every application, I want to use the system version. I don't need the latest and greatest computer science features. I just need something that can do almost everything and keep doing it reliably forever* (*in computer tech terms 10yr+). It does exist but it's rare.

1. Figure out the best programming language (it's Scala) 2. Use that for all the applications I build

For legacy stuff, almost by definition, your language is picked for you. If you've got a million lines of VB, then I guess you're using VB, but it could easily be any other language.

For everything else, you either go with what you know, or just try to evaluate the best choice based on the language and toolchain.

I just stretch as much as possible to use Python for every task.

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.

Rust for everything, I could explain but it would get rude

for personal projects, I am leaning heavily towards golang for all things, because the langauge never changes.

I'd rather spend my limited time developing features, not updating the code to the latest node/python/pip/uv/yarn/framework version.

If I don't maintain the code, upgrading is way harder, b/c trying to figure out which dependency works for what version of what framework/language is a nightmare.

Simple task and no dependency = probably C or C++. Or maybe Rust if and when I start using that. Everything else you mentioned, too much runtime baggage.

Elixir is the best programming language for building distributed systems.

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

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.

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.

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

For me, it's easy: It's always TypeScript, no matter what.

if coding a webapp, I use full stack ruby on rails (hotwire/turbo/javascript with importmaps).

System stuff go/pyhon. I haven't had time to learn either Rust or Zig, but I think Golang is good enough for now.

I have a lot of java experience, but to be honest the opensource toolchain outside big tech is too much of a pain to use (say gradle or mvn). I believe SBT is quite good but learning scalla goes into the bucket alongside rust and zig.

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.

Programming language choice is determined by the task at hand. If you want to create frontend web apps, it’s JavaScript/ Typescript. If you want to write an OS, it‘s C/C++. If you do data analysis, it’s R/Python. Apple ecosystem? Swift. You can continue the list. By looking at domains and dominant languages. What resources are there for your domain, what have others contributed to, what libraries/ packages are there, what’s the mindshare, etc

I am seriously starting wiegh highly, "What languages will generative AI work best with?" Either from a baseline model aptitude aspect or that the language itself provides structural guardrails that lower runtime issues.

This comes after creating several large scale personal projects completely using AI in python.

It is interesting to think about what affordances will make AI most productive.

I try to avoid depending on US mega-corporations.

Step 1: Assign each language a number. Close your eyes and then throw a dart into a dartboard. Then hope it lands on something that the HN hive mind approves and LLMs can write.

Step 2: write a blog post about how your decision has improved application performance, stability, and development time. State as much opinion as fact as you can. Then submit that to HN.

Step 3: enjoy your new found status as a tech leader.

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

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.