Skip to main content
U.S. flag

An official website of the United States government

Dot gov

The .gov means it’s official.
Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.


The site is secure.
The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

Language Selection Guidance

Many factors should influence how TTS engineers make technology selections for their projects. Here, we discuss recommendations on how to select the language used in your projects. This document doesn’t offer hard-and-fast rules, focusing instead on several language aspects1 which should be balanced against each other. Also, we explicitly note that language selection is ultimately the decision (and responsibility) of the project team. The guidance below is meant to assist your team make this decision.

This is a living document2. After looking at existing tickets, start an issue or pull request in GitHub to suggest changes to these standards.

Our strongest languages

TTS has historically worked in three primary languages: JavaScript, Python, and Ruby. While we certainly have a healthy smattering of other odds and ends, these three are our primary strength3 as indicated by data from past projects, engineer skill sets, and billable hours. These languages are generally a safe bet as we know we can support them and be productive with them.

Looking at this same data and applying preferences from the guiding factors below, we also see a second tier of familiarity around Go, Java, and PHP. These languages may be good fits depending on the project at hand. In particular, domain4 preference and client familiarity may be major reasons to select one of these languages for your project. We feel relatively comfortable supporting these languages, but if all other factors are equal, we encourage selecting from our first tier.

Project scope

Perhaps the most important factor5 to weigh when considering languages is the estimated project scope. If we anticipate a large, long-standing project which will be handed off to our agency partners, we should be conservative in our language selection. These projects warrant our most standard approach, which generally translates to the selection of one of our primary languages. On the other hand, if writing a one-off script or small internal project, we have significantly more latitude to try experimental languages.

Let’s consider some examples for reference6. As a reminder, in almost all situations, selecting one of our primary languages is a viable option.


Languages are not all equal10. We next consider a handful of factors to weigh when selecting a language for a project. In no particular order:

Other impact

By setting forth19 the above, we can imagine potential impact on our hiring, project selection, and larger processes. The progression is logical and we may want to use this document as evidence when deciding how to iterate those systems. Concrete details are outside the scope of this document, however, and we anticipate (and proclaim) no immediate changes.