Picking a Programming Language
Picking a Programming Language

I've started a lot of programming projects.

Every time I start a new project, there's the question of "What programming language should it be written in?"

That programming language will often set the tone for the entire development process. It'll decide the team that is built around the project. It can decide what community will contribute to and benefit from the project. It'll often decide whether or not the project will ever be released. It's a deceptively important question.

I have been really bad at it.

Over the past 3 years, I've tried (and failed) to insert Scala into my company's workflow on several occasions. It's sat in the stack, producing errors that no one cares to investigate with side-effects that no one quite realizes. No one learned how to expand upon it.

It was a celebrated day when we removed it from the stack.

Does that make Scala a bad language? No it doesn't. Was it bad at what we were trying to do with it? No, it was perfectly equipped for the tasks at hand.

We were bad at making it do what we want.

It means that it wasn't right for our purposes when paired with our team. It probably won't be right for us for the forseeable future. That's fine, and we're having a great time with the languages we do use.

What languages do we use now? That's not the point.

Let's go through a few of the things you can take into account when deciding the language for your next project!

The list is separated into some of the situations you might be in for this decision.

If you're interested in topics like this, why not subscribe to the blog?

Solo Project

Building a software project on your own? The programming language you pick might seem unimportant.

Due to the reasons mentioned earlier, it's worth thinking about what you're trying to accomplish with this project. Choosing your programming language around that goal.

The language you use can be a help or a hinderence towards your goals.

What languages do you know?

For a while, I tried to learn a new language with almost every personal project I started. I've used insane number - around 16 programming languages - over the course of my career, from doing this.

I've also abandoned a startling number of projects that spend their time sitting in my git repositories, gathering dust and benefiting nobody.

It's not the most fun thing to say, but sometimes it's best to stick with what you know.

Review the list of languages, technologies, and workflows that you've used in the past and make sure that those languages won't fit what you need before deciding on a new language.

Choosing a Language

I've split the rest of this section into different goals you may have and how they can tie into your language choices.

  • Are you trying to learn a new language?
  • Are you trying to learn a new programming paradigm?
  • Building something experimental and fun?

If any of those are true, jump right in!

Leap into the documentation of a language you've heard a lot about and try to make something cool. Learn a ton and expand your toolbelt for your future projects.

This all can be fun, expand your horizons as a developer, and teach you something about your interests that you didn't expect to find!

  • Are you writing a tool for open-source?
  • Are you building for a specific environment (iOS, Android, Windows, Mac, Web…)
  • Are you writing for a specific field or industry (Machine Learning, Fintech…)?

Here is where I'd recommend you really consider you use the language everyone else is using. If you use the tools everyone else is using you will build upon everyone's hard work and it will accelerate your project to a massive degree.

If your project is open source, it will encourage collaboration and help make it easy for the community to contribute. At least be aware of the languages everyone else is using and why they're using them.

Maybe they've tried that path you're considering and hit unexpected obstacles that you can learn from.

If you choose not to use the same language as everyone else, try to think of a reason for it.

I worked for a long while to build a memory-editting tool in Ruby.

The reason was that I loved the simplicity, readability and ease-of-use of the Ruby language. I had never seen a programmable bot-making or trainer-making language for video games that had that combination of ease-of-use and raw memory modification.

Everything I wrote was going against the grain and made me work much harder than if I had picked the lower-level languages that everyone else had been using for decades.

Every method I wrote took 10x longer than it should have. Problems came up that had never been documented or solved, anywhere I could find on the internet.

That was alright. It was alright because I knew that'd be the case and I wanted to do it anyways. I knew I'd probably never finish it but I wanted to try because I thought it was a fun and worthwhile goal.

It's fine to go against the grain if you're aware of that and want to continue anyways.

  • Do you want to finish the project?

If you want to finish the project and get it to the point where other people will find it useful, I implore you to consider choosing a language you already know.

Starting a project and getting it off the ground is hard enough already. Adding the overhead of learning a language to the mix is just asking for the project to run into trouble.

The language has a few other implications that come with it. Think about** the stack**, the *deploy process*, the *debugging*, the *testing*, the *available libraries*, the *surrounding toolset*, and surrounding *community*. It's a lot to figure out and if you have a setup that you're already comfortable with, you have to consider what you're sacrificing.

If others start using the project, you want to be able to confidently tell them that it's stable and will be able to handle their needs. That becomes harder when you only have a few months under your belt with the technologies involved.

If the languages you have under your belt will definitely give you significant trouble, or you are just extremely tired of them, that's an OK reason to ignore this advice. Perhaps the love you feel for this new language, or the benefits you get from the new language's community, will give you the boost you need to get past the obstacles ahead and release the project.

Whatever you choose, learning a new language while building a serious solo project will likely be one of the tougher challenges you face in your career!

Project with a not-yet-created Team

This is a section for projects where there's currently no team, but where a team is planned to exist in the future. Ambitious projects that you might plan on building a startup, organization or small company around.

For this section, I'm going to break it down with some positions you might currently be in.


If you are a freelancer, and you know the company you're building will mainly hire other freelancers in the future, please really consider using the language that all the other freelancers are using (in your space).

You might not love the language. You might hate it. It might have a bunch of issues and it might be pretty ugly and hard to maintain.

If you build the application in a language that it's hard to find a freelancer for, you're putting the client in a bind that's really hard to get out of.

If the client succeeds, they'll need to expand upon the application you write. If they do this through freelancers, the language it's written in or the technologies they use can dramatically lower the pool of people who they can hire. This smaller pool can raise prices to amounts the client can't afford and kill an otherwise growing business.

If you choose a different language, take this problem into account and make sure the productivity gains outweigh the downsides.

Founding member

  • What language will be easier to hire people for, in the next year or so?

If the language you use becomes unpopular in that timeframe, a large number applicants will start politely declining your job offers when they hear what they'll be working with. If you use a language that's too new or too niche, the applicant pool will be much smaller and more expensive.

  • What language will help you keep the codebase in a clean enough for a new engineer to understand it?

If everything's a mess by the time they get there, the productivity loss suffered by your future engineers or by rewriting the application can grow to insane levels at the worst time.

  • How approachable is the language (for new engineers)?

A team of entirely new engineers can be a mess.

A team of entirely senior engineers can be even worse.

A good mixture of new and senior engineers can be a great environment where the new engineers are enriching their careers by learning new technologies and the senior engineers are enriching their careers by learning to convey their ideas and teach in an approachable way.

What language can a new engineer reasonably learn and become productive in? What will provide an enriching and empowering experience?

  • What are other teams using in the space?

It's always a good idea to take a look at what everyone else is using and why. There might be obstacles in the way that you can't predict. Seeing others hit those obstacles first and learning from them can save a lot of time and heartache.

  • What languages do you know?

Whether you like it or not, you're setting the standard for this codebase. You're going to be expected to lead and defend it. Every bug that new team members see in it will feel like a punch in the gut for the first few years.

Choosing a language that you feel comfortable in can make this a lot less painful. If people ask you questions, you can answer them. If bugs come up, they aren't ones that could have been easily avoided. When you show the code to new team members, you won't cringe and hope that they don't see the warts.

It can sometimes be beneficial to stick with what you know. You are starting an ambitious project. Life's likely going to be hard for a while. Thinking about these things can prevent some troubles and make things just a little bit easier.

Project with an Existing Team

When working with a team project, the stakes can be a bit higher. People's careers are in the mix as well as their day-to-day happiness. Here are some factors that have proven useful to think about when deciding this.

What languages does the team already know?

What is everyone on the team already good at? This doesn't sound like the fun answer, but it can be.

If everyone is already good at writing in a language, they can work together to create a really solid, extensible application. They know all the caveats. They know the build and deploy process. They all can set up a nice local environment. The legacy application might be annoying to work with but the new one can be better.

Everyone can come to work knowing that they will not spend the day dealing with crashed servers and impossible-to-reproduce bugs.

Does everyone hate their job?

I'm very lucky to say that my current team hasn't had this issue.

But, I've been on and seen teams that have gotten into such a large rut, such a productivity hole, that mention of more of the same will eventually tear the team apart.

It's expensive to learn a new language. It's more expensive to replace an engineering team.

If you think that this is the case, ask your team what language they'd like to use in this next project. Ask them how they think you'll be able to get out of this productivity hole that you've found yourselves in.

If they tell you what they think, invest in making their ideas work. Make sure that everyone has the resources they need to learn this new technology at a good pace. Make sure that you're able to deliver results often and in small increments while this learning is going on so that you don't lose faith from the overall organization.

Sometimes, a new language or technology can add the spark needed to get people excited again. Investing in what your coworkers want and empowering them in their careers, creating an atmosphere that encourages that, is a sure way to make coming into work a little bit better every day.

What are other teams in the market using?

It is very rare that your team knows something that the rest of the industry doesn't. It's never a bad idea to take a look at what everyone else is using and why.

Building an analytics system? What are all the other engineering teams in the analytics space using? What are the major and upcoming technologies? What are they written in? It'd be even better to find out why they're written in that language.

At the very least, you'll know that your competitors were able to use the technology and make it work. It's proven to be usable enough to build a company around it.

Keep that in mind when deciding your own language and technologies and it'll help you make a good decision for your specific engineering team!

Moving forward

Hope I've helped in your search for the right language! At the very least I hope that I've helped you think about something you hadn't considered before.

Go out there and make something awesome!