Programming languages
We use a range of programming languages at MHCLG 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 TypeScript.
MHCLG projects using TypeScript include:
- Electoral Registration Officer portal
- Register to Vote
- Apply for photo ID to vote
- see repositories in TypeScript
You can use TypeScript when teams think it’s appropriate. For example, if you prefer a a statically typed, compiled language, and with static-analysis tooling.
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.
We are also currently exploring the use of Rust in the backend for applications that are computationally demanding and need to run fast, particularly in the Energy Calculation as a Service project.
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.
Languages we do not use for new projects
We used Java in the development of Delta and E-CLAIMS. These are the only remaining applications written in Java, but we’ve found it hard to support because of a lack of skills in MHCLG. Do not use Java for new projects.
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
- 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 the tech lead for your project. 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.