Go

Why blocking is free here

A goroutine is not a thread. It starts with a stack of a couple of kilobytes that grows as needed, so creating a hundred thousand of them is ordinary rather than reckless. The Go runtime multiplexes them onto a small number of real operating-system threads — as many as you have cores, by default — and schedules them itself.

The consequence is the thing worth carrying away. When a goroutine makes a blocking call — a database query, an HTTP request, a file read — the runtime parks it and hands its run queue to another thread, so nothing stalls. You get the scalability of an asynchronous server while writing code that reads top to bottom, with no callbacks, no promise chains, no coloured functions and stack traces that mean what they say. Node solved the same problem by making everything asynchronous; Java arrived at Go's answer two decades later with virtual threads.

Goroutines talk through channels: a typed pipe where a send blocks until a receiver is ready, and vice versa. That blocking is the synchronisation — passing a value through a channel transfers responsibility for it, which is what the community slogan "share memory by communicating" means in practice. select waits on several channels at once, and combined with context it is how a request cancels the work it started when the client goes away.

Channels are not the answer to everything, and new Go developers overuse them. When several goroutines simply need to read and write one shared structure, a sync.Mutex is clearer, faster and easier to reason about than a channel-based protocol. Use channels to hand work over and to signal; use a mutex to protect state. And run the tests with -race, because Go will happily let two goroutines write the same map and the race detector is the only thing that will tell you.

Errors are values

Go has no exceptions. A function that can fail returns an error alongside its result, and the caller checks it. This is the design decision people argue about most, and the argument misses what it buys: every place a failure can occur is visible in the code, at the line where it happens, and there is no invisible path by which control leaves your function. You cannot forget to consider an error, because the compiler will not let you ignore the variable you declared to hold it.

The cost is repetition — the three-line check that appears everywhere. Modern Go softens it: wrapping an error with fmt.Errorf and %w builds a chain that carries context up without losing the original, and errors.Is and errors.As inspect that chain at the top, where the decision belongs. The pattern to aim for is that low-level code adds context and returns, and exactly one layer near the boundary decides what to do — log it, retry it, or turn it into a status code.

Deliberately small

Go leaves out features other languages consider essential, and the omissions are the design rather than an oversight. There is no inheritance — types embed other types and satisfy interfaces implicitly, without declaring that they do. There are no constructors, no operator overloading, no default arguments, and until recently no generics. The point of all this is that Go code written by a stranger looks like Go code written by you, which is what makes a large team on a large codebase workable.

Two more things shape day-to-day work. gofmt ends every formatting discussion by making the formatting non-negotiable — there is one layout and the tool applies it. And the standard library is unusually complete for a backend: an HTTP server, JSON, TLS, templates, testing and profiling are all in it, so a production service can genuinely have almost no third-party dependencies. Generics arrived in Go 1.18 and are useful for containers and utility functions; they are not an invitation to rebuild the type-level machinery of another language.

How this shows up in real delivery

The operational story is why Go took over infrastructure. The build produces one statically linked executable with no runtime to install, which means a container image measured in megabytes, a start-up measured in milliseconds, and a deployment that is a file copy. Docker, Kubernetes, Terraform and Prometheus are all written in Go, and that is not a coincidence — those are exactly the programs where a small, fast, dependency-free binary is the requirement.

Go's garbage collector is tuned for latency rather than throughput: pauses are typically well under a millisecond, and it achieves that by doing more work concurrently and using more CPU than a throughput-focused collector would. For a service, that is the right trade. The tooling to see what your program is actually doing ships with it — pprof for CPU, memory and goroutine profiles, and the race detector under go test -race, which should be part of CI rather than something you remember to run.

Where it degrades

• Goroutines started without a way to stop them, which leak for the life of the process and grow with traffic.
• Errors returned unwrapped, so a failure ten layers down arrives as "connection refused" with no context.
• panic and recover used as an exception mechanism for ordinary, expected failures.
• Channels used where a mutex was the simpler tool, producing a protocol nobody can follow.
• Shared maps written from several goroutines without a lock, which the race detector would have caught.
• Layered abstractions imported from Java or C#, which fight the language rather than using it.
• context accepted as a parameter and then ignored, so cancellation never actually reaches the work.

When to use it

Related pages

• DevelopmentJavaJava has been the default language of large back-end systems for thirty years, and it is still the one you find when a bank, an airline or a telecom opens its source tree. What makes Java what it is has less to do with its syntax than with the machine it runs on: bytecode instead of native code, a compiler that optimises while the program runs, and a garbage collector you tune rather than replace. This page covers the JVM, the type system, Spring, concurrency, and what virtual threads changed.
• DevelopmentNode.jsNode.js is JavaScript on the server, and the runtime that made "one process, thousands of connections" ordinary. It gets there by never waiting for anything itself: I/O is handed to the operating system or to a small thread pool, and your code runs on exactly one thread in between. That is its strength for API work and its hard limit for anything computational. This page covers the I/O model, scaling, the module split, and the mistakes that only appear under load.
• DevelopmentMicroservicesMicroservices are an architecture in which a system is built as a set of services that can each be deployed on their own. The defining property is independent deployability, not size — a service is the right size when one team can own it end to end. Everything good about the style follows from that independence, and everything hard about it follows from the fact that the calls between services now cross a network.