The Design Philosophy: What Go Left Out

Most language design optimises for what a programmer can express. Go optimises for something else: what a different programmer can understand a year later, in a large codebase, without context.

That objective explains choices that look like omissions and are decisions.

The reasoning is about where time goes on a large team. Code is written once and read many times, by people who did not write it, often while something is broken. A feature that saves the author five minutes and costs each subsequent reader thirty seconds is a bad trade at scale, even though it is a good trade for the author.

So Go systematically prefers explicit and verbose over concise and clever, and the resulting code is often described as boring. That is the intent rather than an accident.

Whether it is the right objective is arguable and depends on the setting. What is worth understanding is that each omission below was a considered trade, and each has a real cost the enthusiasm tends to skip.

Go has no exceptions. A function that can fail returns an error alongside its result, and the caller checks it.

f, err := os.Open(path)
if err != nil {
    return fmt.Errorf("opening config: %w", err)
}
defer f.Close()

That three-line pattern is the most criticised thing about the language, and the argument for it is specific.

With exceptions, every call is a potential branch out of the function, and the branches are invisible. Reading a function does not tell you where control can leave it, which is a real problem in code that must release resources or maintain invariants.

With error values, control flow is visible. Every place the function can return is written down, and a caller ignoring an error has done so on a line you can see in review.

The cost is real. The pattern is verbose, it dominates the visual weight of the code, and it makes the happy path harder to pick out. The %w verb wrapping errors preserves the chain so callers can inspect the cause, which recovers some of what a stack trace would have given.

The deeper trade: exceptions make the common case concise and the exceptional case invisible. Go makes both explicit, and pays for it in every function.

A type implements an interface by having the right methods. There is no declaration, and the type does not know the interface exists.

type Writer interface {
    Write(p []byte) (n int, err error)
}
// Any type with that method is a Writer. No inheritance, no registration.

The consequence is that the consumer defines the interface, not the producer. A package needing only one method of a large type declares a one-method interface locally and accepts that. The original author never anticipated it and does not need to.

This inverts the usual dependency direction. In languages with explicit implementation, using a type as an interface requires the type's author to have declared it, so the abstraction must be designed up front, and adapting third-party types means wrappers.

The cultural rule that follows is that interfaces should be small and defined where used. A one-method interface is idiomatic and common; a fifteen-method interface is a design smell.

The cost is discoverability. Nothing in a type's source says which interfaces it satisfies, so finding every implementation of an interface requires tooling rather than reading. That is a genuine loss, traded for the ability to abstract over code you do not control.

There are no classes and no inheritance. Types are composed by embedding: placing one type inside another promotes its methods to the outer type.

type Logger struct{ prefix string }
func (l Logger) Log(msg string) { fmt.Println(l.prefix, msg) }

type Server struct {
    Logger              // embedded: Server now has Log
    addr string
}

s := Server{Logger{"[srv]"}, ":8080"}
s.Log("started")        // promoted method

This looks like inheritance and differs in one decisive way: there is no subtyping. A Server is not a Logger and cannot be used where one is expected, unless it separately satisfies an interface. The relationship is has-a rather than is-a, even though the call syntax is the same.

What that removes is the fragile base class problem and the deep hierarchies that make behaviour hard to locate. With inheritance, finding what a method does means walking up a chain of overrides. With embedding, the method is on the embedded type, and the chain is one level.

The cost is that genuine polymorphic hierarchies must be expressed through interfaces instead, which is more verbose for cases where inheritance genuinely fits, and there are such cases.

Read the right column as costs rather than benefits, because that is the half usually omitted.

The formatting decision is the most striking. gofmt defines one canonical layout and there is no configuration, so every Go file in the world looks the same. That removes an entire category of team argument and review comment, and it means unfamiliar code has no unfamiliar shape.

The cost is that you do not get to disagree, including when you are right about a particular case. That is the trade accepted deliberately: the value comes from universality, so allowing exceptions would destroy it.

The same reasoning covers the compiler rejecting unused variables and imports as errors rather than warnings. It is infuriating during exploratory work, and it means no Go codebase accumulates the dead imports and abandoned variables that every other language's codebases collect.

The pattern across all four: a small, permanent, individual cost in exchange for a property that holds across an entire ecosystem.

Go's standard library is unusually capable for infrastructure work: a production-grade HTTP server, TLS, JSON, compression, cryptography, templating and testing, all in the distribution.

The consequence is a dependency graph most ecosystems do not have. A substantial Go service can be written with very few third-party packages, which means fewer supply-chain surfaces, fewer version conflicts, and fewer abandoned libraries.

The design principle visible throughout is small interfaces composed. io.Reader and io.Writer have one method each, and almost everything in the library accepts or returns them, so a file, a network connection, a buffer, a compressor and a hash all interoperate without adapters.

That is a better illustration of the language's philosophy than any list of features. The abstraction is tiny, defined by behaviour rather than hierarchy, and composable precisely because it demands so little.

The honest counterweight: batteries included also means batteries frozen. The compatibility promise that keeps old code working also keeps early design decisions in place, and some standard library APIs show their age with no route to changing them.

The omissions have edges, and being straightforward about them is more useful than advocacy.

Repetition. Without generics, the language spent a decade copying slice-manipulation code per type or dropping to interface{} and losing type safety. Generics arrived in Go 1.18 and were resisted for years precisely because they conflict with the readability objective: generic code is harder to read, which the design deliberately weights against.

Error handling verbosity. In a function performing eight fallible operations, more than half the lines are error checks. Proposals to shorten it have been debated for years and rejected on the grounds that any shorthand makes the error path less visible, which was the point.

Nil. Nil pointers panic at runtime, and nil interface values have a famously confusing behaviour: an interface holding a nil pointer is not itself nil. The lesson Types as Propositions describes the alternative, where absence is encoded in the type and unhandled cases do not compile. Go did not take it.

Weak enums. Constants and a type give a convention rather than a closed set, so exhaustive matching cannot be checked.

Each is a real cost, and each traces back to the same objective. A language that will not add a feature unless its readability benefit exceeds its complexity cost will end up without features that are genuinely useful.

Read down the middle column and a single objective appears: make a large codebase, worked on by many people over years, remain comprehensible. Every row serves it, including the ones that are annoying daily.

The comparison with the previous cursus is instructive. Rust makes the compiler reject anything it cannot prove safe, paying in a steep learning curve for guarantees checked mechanically. Go makes the compiler accept almost anything and relies on convention, tooling and the race detector, paying in bugs the compiler could have caught for a language learnable in a week.

Neither is correct in general. They optimise different variables, and the transferable question is the one both answer explicitly: what are you willing to give up, and what do you get for it? A language design that cannot answer that has not made a choice, only an accumulation.