Go
What you're agreeing to when the backend is written in Go
The short answer
Go is a compiled programming language from Google, kept deliberately small so any Go developer can read any Go codebase. It builds to a single self-contained file you copy onto a server, and holds large numbers of simultaneous connections cheaply. It suits networked services and infrastructure, and gives less scaffolding than Django or Rails.
You went to look up the word Go in your proposal and got results about a board game. That's a real problem with the name, and it's why it gets written as golang online. Underneath it is a plain tool with a strong opinion about what a language should leave out.
A small language, and the smallness is deliberate
Go is a programming language, a different category from most of the words next to it in a quote. Not a platform you sign into, not a hosting company, not a framework with pages and forms in it.
It came out of Google, went public in 2009, and reached version 1.0 in 2012. What's unusual isn't what it added. It's what its designers refused to add. No classes and no inheritance. One keyword for loops where most languages have three or four. Generics, which nearly every other mainstream language already had, arrived in 2022.
The brief was a company where thousands of engineers commit to one enormous codebase and every team has drifted into its own dialect. Rob Pike's account of why Google built it lists slow builds, invisible dependencies, and programmers using different subsets of the same language. The goal became readability at scale, and you'll see the cost of that in the code. Go runs longer and plainer than the same thing written elsewhere. Leave an unused import and the compiler refuses to build, and a tool called gofmt rewrites your code into one layout so nobody argues about formatting.
The build produces one file, and that changes what deployment means
Most languages hand a problem to the server. A Python or Node service needs the right version of an interpreter on the machine, plus every package it depends on, still there next month.
Go compiles instead. One command turns your source and every library it uses into a single executable file with the language runtime inside it. Copy that onto a Linux server and run it. Nothing gets installed first, container images get very small, and building for a different kind of machine is two environment variables, so a developer on a Mac produces the Linux binary without a Linux machine.
The caveats are minor. The binary is measured in megabytes even for a trivial program, and code calling C libraries gives up some self-containment.
01
Source and libraries
Your code, plus a list naming every outside library and the exact version of each.
02
One build command
Go compiles the lot together, dependencies included. Build speed was an original design goal.
03
A single binary
One executable file with the language runtime packed inside it.
04
Copy it and run
The target machine needs no interpreter, no packages and no matching version of anything.
Doing many things at once is what it's known for
A web service spends most of its life waiting. On a database, on another company's API, on a phone with one bar of signal. The hard part is holding thousands of those waits at once without the machine buckling.
Go's answer is the goroutine. Put the word go in front of a function call and it runs alongside everything else. Go's own scheduler manages them rather than the operating system's, so one program holds far more of them than it could hold system threads. They pass work through channels.
That's why so much of the plumbing the internet runs on is written in Go. Docker, Kubernetes, Terraform and Prometheus are all Go programs. An API serving many clients at once, or a service coordinating several others, is home ground.
Where it stops, and it isn't speed
The ceiling that catches buyers out is the ordinary database-backed application. Users, records, forms, a login, an admin screen for staff. The most common thing anyone builds.
Go will do it, and its standard library serves web traffic well enough that plenty of large applications are built this way. But there's no Django here and no Rails. Nothing official hands you a database layer, migrations, a login and a generated admin screen on the first afternoon. Each is a separate decision.
For a team that has built that set before, the decisions are already made. For a first build against a deadline, it's work a Django or Rails team would have skipped. Be sceptical if the only answer to what you get in exchange is speed.
Two other stops. Data science and machine learning belong in Python, where the libraries live. And Go is garbage collected, which is right for services and wrong for the tightest latency and memory budgets, where C, C++ and Rust sit.
Go, assembled
A framework with the parts chosen
- The first week
Go, assembled: You pick the database library, the migrations and the login before any feature exists.
A framework with the parts chosen: All three arrive on day one, with conventions you didn't choose and can't cheaply leave.
- Finding an answer
Go, assembled: Fewer worked examples for ordinary web problems, more for infrastructure.
A framework with the parts chosen: Years of tutorials, much of it written about versions you aren't running.
- Reading it in year three
Go, assembled: Little hidden behaviour, so more lines to read before you understand it.
A framework with the parts chosen: Short code, with much of what it does living in the framework, not the file.
What it asks of the people who keep it running
The upkeep is unusually light, and that's a fair share of the case for it. The tools that format, test and profile the code ship with the language, so there's no build pipeline to maintain. A new version arrives roughly every six months, and the Go 1 compatibility promise says code written against Go 1 keeps compiling on later releases.
Hiring is the part to think about. Fewer developers write Go than write JavaScript or Python. It's built to be read quickly, so a capable developer from another language becomes useful faster than in most. The question for a vendor isn't whether they know Go. It's who else could pick this codebase up.
Worth knowing before you start
Ask to see the service running as a single file on a plain machine, nothing installed beside it. If the build has quietly acquired other requirements, you're carrying the language without the benefit.
For an application with users and records, ask which libraries handle the database, the migrations and the login, and who picked them. Three separate decisions in Go, and the answers say whether the team has done this before.
Ask whether the tests run with the race detector switched on. It ships with the language, turning it on is one flag, and it catches the class of bug that doing many things at once introduces.
Inheriting a Go service? Find out which version it targets and try the upgrade early, while nothing is on fire. Being the exception to Go's compatibility record is better found on a quiet Tuesday than during an incident.
Common questions
Yes. One language, two names. Go is the official name, and golang stuck because it was the website address and because searching for a two-letter word is hopeless.
For most server work, yes. It compiles to machine code and holds many simultaneous requests with less machinery than either. That's rarely the honest reason to choose it. A slow application is far more often a database or an architecture problem.
Fair question about any technology with one company behind it. Go is open source, developed in the open, and a lot of infrastructure other companies depend on is written in it.
It can be, since one Go process handles a lot of waiting at once and uses memory predictably. Treat that as a side effect, not the business case.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.