Programming languages
We use a range of programming languages at GDS because we think using the right tool for the job gives us the best chance of building services that best meet users’ needs. This document does not apply to choosing ‘off the shelf’ software (open source or not).
We focus on using a small number of programming languages for core software development tasks.
This should make it easier for developers to:
- move around the organisation
- develop shared components
- improve their personal development
- master how they operate applications
Frontend development
The Service Manual has information on using client-side JavaScript. For server-side JavaScript we use Node.js.
GDS projects using Node.js include:
- GOV.UK Frontend
- GOV.UK Pay
- GOV.UK Prototype Kit
- GOV.UK One Login - see repositories in TypeScript and in JavaScript
You can use Node.js to render a web interface for your service. For example, GOV.UK Pay has created thin, client-facing applications that do not store data (although they may retrieve data from an API).
You can use TypeScript if your team decides it’s appropriate. There’s more information about TypeScript on the Node.js page.
Backend development
Our core languages for backend development are:
We’ve chosen these languages because they are successfully used by teams at the moment, and we are confident in how to host and operate applications written in them. You should carry out new development in one of these languages.
Python
You should write new Python projects in Python 3. Python 2 reached end of life in 2020. Python 3 is now well-supported by application frameworks and libraries, and is commonly used in production.
Go
Go is an actively used language at GDS, owned and maintained by the GOV.UK Platform Engineering team — the primary team using Go in GDS.
The team uses Go for:
- Kubernetes operators and controllers
- Command-line tools
- APIs and microservices
- Crossplane composition functions
The GOV.UK Platform Engineering team’s use of Go is closely tied to the CNCF (Cloud Native Computing Foundation) ecosystem. A significant proportion of CNCF tooling — including Kubernetes itself, as well as tools such as Helm, Flux, and Crossplane — is written in Go. This makes Go the natural language choice for platform engineering work.
The team also maintains existing Go services including the GOV.UK Router and GOV.UK Mirror.
If you are working outside a platform engineering context, you should use one of the other supported backend languages listed above. Go may also be appropriate for systems programming tasks such as proxying, routing, and transforming HTTP requests, where no suitable maintained open source tool exists.
Refer to the Go style guide for coding conventions and tooling recommendations, and contact the GOV.UK Platform Engineering team in #govuk-platform-engineering if you have questions.
Languages we do not use for new projects
We used Scala in the early days of GDS. GOV.UK Licensing is the only remaining application written in Scala but we’ve found it hard to support because of a lack of skills in GDS. Do not use Scala for new projects.
Mobile development
For developing mobile apps, we use:
To give users the expected experience on their respective platform, we prefer to use the native languages over cross-platform solutions.
Swift
When starting a new app project, you’ll likely want to use the most recent version of Swift which will be installed with Xcode.
Kotlin
We prefer to develop Android apps using the latest stable version of Kotlin.
Using other languages
There will be sensible reasons to not follow the above guidance on languages. For example when you’re:
- extending an existing codebase or ecosystem
- scripting in a particular environment
- experimenting during an alpha (with an expectation that it’s replaced by something we have more confidence in for beta)
- working in a very specific or unusual problem domain, like heavy use of WebSockets
The set of languages we’re comfortable supporting will change over time.
If you want to use a new language, talk to your Head of Technology and then create a prototype. If it goes well you can open a pull request to change this document.
If you’re having problems using one of the languages we support, open a pull request to document the issues.