Ask HN: How do you choose languages for building applications?
Say, i want to build tcp client for check connection and can deploy anywhere without install any dependency, so i think golang would be a great choice. Maybe because your team are more comfortable with Python or dealing with AI/ML stuff, Java if you're dealing with Android apps, or because you are working on bank company, Rust for efficiency or some web server, Elixir i heard it's good for building messaging apps, C# for games, and even visual basic if you're dealing with legacy stuff.
47 comments
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.
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.
my team are familiar with python, but i am not, so i decided to take an opportunity to learn this language, although, i prefer to use go because it's lightweight and simple.
at home i built my application using go. i also want to learn rust and elixir, but honestly i am not sure why i should learn both of them. i think language programming are just tools but they have their own advantages. also, learning other languages helps me become a better engineer.
at home i built my application using go. i also want to learn rust and elixir, but honestly i am not sure why i should learn both of them. i think language programming are just tools but they have their own advantages. also, learning other languages helps me become a better engineer.
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.
Also, you can ship fast and write more performant version, possibly in different language, later.
Although sometimes the choice is so you can learn that language, which is absolutely the best way to learn a new programming language.
Absolutely! I always tell people who want to learn to program to have a goal in mind. Something they want to actually build and use, not just yet another todo list they do not care about and won't touch ever again. In a way, it is better to have a problem first, then learn a programming language to fix that problem instead of the other way round.
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.
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.
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.
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.
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.
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
- 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
sounds like you'll love Elm and/or Nim haha
this is why i've loved golang since i've started using it 10ish years ago. stdlib is small, but the foundation is strong, and api changes are few and far between. it's nice to work in a language where i don't need to reach for 5 million libraries to do everything, and if i come back to it in a year or so i dont need to learn a new package manager, testing framework like with python / js
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.
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.
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.
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.
>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.
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.
Then my teams ignore all that research and build it in the language they build everything in.
I just stretch as much as possible to use Python for every task.
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.
For everything else, you either go with what you know, or just try to evaluate the best choice based on the language and toolchain.
Simple — Rust for everything except Typescript for browser/mobile and Python for scripting.
* Which languages suits the problem as of 2025? (About all: performance, deployability, ecosystem.)
* Which languages I know (or are willing to learn) - and so do my collaborators?
All in all, it is if a language gets job done within constrains. Everything else id details.
* Which languages I know (or are willing to learn) - and so do my collaborators?
All in all, it is if a language gets job done within constrains. Everything else id details.
For me, it's easy: It's always TypeScript, no matter what.
Rust. I choose Rust. That's my language selection procedure.
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
For a professional/work context, I think this is mostly a human (rather than tech. decision). What languages are the team comfortable in? Where is talent available etc.
If you're in services, then the general demands of the market/your niche are important factors.
For completely personal projects, if you're trying to learn language X, use X. If you're trying to build a project for some reason, then use the language you're most familiar with.
If you're in services, then the general demands of the market/your niche are important factors.
For completely personal projects, if you're trying to learn language X, use X. If you're trying to build a project for some reason, then use the language you're most familiar with.
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.
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.
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.
1. Figure out the best programming language (it's Scala) 2. Use that for all the applications I build
same
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.
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.
I usually use some obscure dialect of Brainf*k, this means:
- Everyone thinks I'm smart,
- The client has to return to me for the simplest changes ($$$),
- I get paid to practice my favourite language,
- Everyone thinks I'm smart,
- The client has to return to me for the simplest changes ($$$),
- I get paid to practice my favourite language,
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.
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.
I try to avoid depending on US mega-corporations.
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.
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.
Honestly, I have a few favourites and just use those.
Low level stuff, my go-to these days is Odin. Just super pleasant to use. Also super easy C-FFI, so it can interact with most code out there with a small amount of effort.
Web stuff, random scripts, utilities, etc... Ruby. For pretty much the same reason: it's pleasant and easy to use. Obviously easier than Odin because no need to manage memory and much higher level. It's FFI also allows you to interact with most languages (including Odin, in just a few lines of code).
Also, I should mention, I use stuff like JS, Java, C/C++ as needed. Sometimes there's a library you need, a platform where one of those is needed to glue it together, JS for web front end, etc...
Low level stuff, my go-to these days is Odin. Just super pleasant to use. Also super easy C-FFI, so it can interact with most code out there with a small amount of effort.
Web stuff, random scripts, utilities, etc... Ruby. For pretty much the same reason: it's pleasant and easy to use. Obviously easier than Odin because no need to manage memory and much higher level. It's FFI also allows you to interact with most languages (including Odin, in just a few lines of code).
Also, I should mention, I use stuff like JS, Java, C/C++ as needed. Sometimes there's a library you need, a platform where one of those is needed to glue it together, JS for web front end, etc...
Elixir is the best programming language for building distributed systems.
Languages are tools.
Use the right tool for the job.
Use the right tool for the job.
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.
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.
Rust for everything, I could explain but it would get rude
chose the one I am familiar with
Static typing is a must unless the compromise is worth it. For instance even without static typing Elixir is worth it for OTP and the preemptive scheduler (VM) is just a bonus.
But then you also have to include what type of application it is. Real time or soft real time, etc.
But then you also have to include what type of application it is. Real time or soft real time, etc.