When setting out to build a tech-enabled delivery network, we knew the challenges our tech stack had to meet: reliability, performance, and fast iteration. Our engineering team had to decide on a programming language to use for our backend platform, and we chose Go, a type-safe, performant, and modern language.

Here’s all the things we’ve loved about Go, the libraries we use, and the tooling we’ve put in place, for the best possible developer experience.

Our favourite library - lo

Go is a very simple language that offers excellent benefits, including a shallow learning curve. But sometimes simple things can require more boilerplate code than ideal. One of our favourite libraries is samber/lo, which is a lodash style library for Go, which those from a JavaScript background will likely be familiar with. This differs from idiomatic Go, but can result in much easier-to-read and maintain code.

A great example is lo.Filter(), which results in fewer lines and easier-to-read code.

The most common one across our codebase would be lo.Map(), which is fantastic for tasks such as extracting fields from arrays of objects. As well as some simple functions, such as lo.Uniq(), and lo.IsEmpty().

Linting

For linting, we use the popular goclangci-lint tool. This is highly configurable, and runs multiple linters together, all at once. Linters are highly valuable for identifying likely bugs, and keeping the quality of our codebase high.

HIVED uses domain-driven design. Taking one of our domains, the Sender domain, we have 34 linters configured, that can all be run together, really quickly. These range from linters performing simple actions such as styling, e.g. pointing out that “accountId” should be “accountID”, to more advanced linters such as “ineffassign”.

The ineffassign linter spots any scenarios where assigning a value to a variable has no impact. This is one our highest signal-to-noise linters, it has very minimal false positives, but any issues it does find are highly likely to be bugs. This can be particularly effective at identifying scenarios where error values aren’t checked.

In this example, you might think that other linters would identify that `err` is unused, or that it’d even be a compiler error. But sadly, it doesn’t count as unused, because the variable as a whole is used, even if the value assigned on line 2 isn’t used; `ineffassign` will identify that the assignment on line 2 has no effect, and thus identify the bug.

Spec-driven development

For our main API services, we define the API in an OpenAPI YAML file, then use oapi-codegen to generate all the boilerplate Go code. This speeds up development, and provides input validation and parsing automatically, and means that our application code can safely use the automatically generated types.

Just as we automatically generate server code from our API spec, In our frontend projects, we generate client code to call our API. This means there’s never a mismatch between the types in our frontend and what’s available on the backend, eliminating an entire class of bugs.

Cross-compilation

There aren’t many languages that make cross-compilation as easy as Go. Cross-compilation is compiling for one platform (like Linux) from another platform (like MacOS).

At HIVED, all our engineers are given MacBooks, but our deployments run on Linux. If an engineer wants to do a quick deployment to our development environment, they can rapidly build for Linux directly from their MacBook. We can compile one of our main services in just under a second.

Taking our Sender domain as an example, which comprises several microservices. They can all be compiled and deployed in under 30 seconds. 

AI coding

Just as important as having a great developer experience for humans, is also having a great experience for AI coding agents. Our engineers use tools such as Claude Code and Cursor. And we’ve found that lots of the features that have been useful for us, like: formatting, linting, and testing, are even more important for AI coding agents that need rapid feedback to be effective.

—

Go has given us the performance, reliability and developer velocity we need to build a delivery network that can scale with our ambition. To keep up with what we are building, look out for the next blog in this series or come and join our team here!