Table of contents

The GDS Way and its content is intended for internal use by the GDS community.

Programming languages

This document is current until 4 December 2018

We want to use a range of programming languages at GDS because we think using the right tool for the job will give 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 want to 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 that use Node.js include: GOV.UK Frontend, GOV.UK Pay, Performance Platform and GOV.UK Platform as a Service.

Node.js can be used to render a web interface for your service but should not be used to implement any significant ‘application logic’. For instance GOV.UK Pay has created thin, client-facing applications that do not store data (although they may retrieve data from an API).

In the past we’ve had problems operating and maintaining products written in Node.js (for example maintaining dependencies, picking the appropriate libraries to use, understanding the appropriate application structure, and ensuring security of the code). We suspect that this is because:

  • It’s younger and less mature than Java, Python and Ruby
  • We have fewer developers with Node.js skills than other tools we use

Node.js is now frequently used in the wider software development ecosystem for building web application frontends. This increase in Node.js use means there has been a growth in skills and supporting tools and we expect this to continue. This means we may reevaluate it as a core language in the future.

Teams that adopt Node.js must take steps to ensure that they have access to sufficient developers with Node.js experience.

Backend development

Our core languages are Java, Python and Ruby.

We’ve chosen these 3 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. We’d advise you to carry out new development in one of them.

New Python projects should be in Python 3. Python 2 will reach end of life in 2020. Python 3 is now well-supported by application frameworks and libraries, and is commonly used in production.

The GOV.UK router is built using Go, and it’s the core language for Cloud Foundry which runs our Platform as a Service.

Go is an appropriate language for some systems programming, like proxying, routing and transforming HTTP requests. However, since we don’t maintain much Go and thus are likely to have few people with the skills to do so, any such code poses a significant risk. Components should only be written in Go if there is no alternative maintained open source tool which could be used, and after a team has developed a plan to ensure that it will have the skills to maintain the component in future.

Languages we won’t 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 and we’re planning to rewrite it. Do not use Scala 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
  • 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 technical architect and the Deputy Director Technology Operations and then create a prototype. If it goes well make a pull request to change this document.

If you’ve had problems using one of the languages we support, make a pull request to document the issues you’ve had.