Choosing a Programming Language: A Checklist

✔️ Do you know the programming language?

Unless this is a side project to learn a new language - you're unlikely to achieve any meaningful developer velocity while learning a new language.

✔️ Is the programming language at use at your company already?

Don't be the person that introduces Haskell in production.

At Google, there are official languages that are allowed in production for a good reason. New languages aren't just complex to develop, but they are complex for DevOps and Site Reliability Engineers (SREs) to manage.

✔️ For the domain you're targeting, can you easily consume relevant libraries?

Most programming languages are expressive enough to handle nearly any domain. Having client libraries for the dependencies you consume will save you considerable time and effort.

✔️ For the domain you're targeting, can others easily consume your code?

Your code does not live in a vacuum. This is especially important if you're planning to open source your code.

Making it easy to consume and use by others will not only make your code better by soliciting contributions from others, but it will

✔ Will the new language integrate well with the existing infrastructure and projects?

Some languages work together better than others. Compiled languages have similar developer workflows. Production profiles of garbage collected languages look more similar than those that are not.

Serialization formats, messages queues, and RPCs are ways to combat this overhead, but they might not exist in your infrastructure yet. Containers are another language agnostic way to ship production environments, but bring a similar infrastructure overhead when introduced.

Reasons not to choose a programming language

❌ Performance

Unless this is an explicit requirement for your domain and you're building something that is:

  • "Planet-scale" service (Google)
  • Ultra-low latency (High Frequency Trading, low-level proxy, embedded)
  • Unique hardware requirements (embedded, FPGA)

I guarantee that your crap code will be more of a bottleneck for optimization than the underlying language. And if the project survives long enough to have sophisticated enough performance tools to understand the problem, then you can rewrite those critical paths in C.

❌ Portability

Unless you're writing a fundamental low level library, your code probably won't be used on multiple architectures. Most high languages today are portable enough - Go, Ruby, Python, Rust, Javascript, Java.

❌ Fear of Obsolescence

In fact, maturity brings expertise. Bugs have been found and fixed, libraries have been written, tools have been created. You would be surprised at the sophistication of some of the C++ and Java tooling, as well as the engineers that work with them.