boring on purpose
Go's ideology is that a language should stay small on purpose. Its designers put in only what all of them agreed earned its place, and left the rest out — less is exponentially more, as Rob Pike put it. Every feature omitted is one fewer way to say the same thing: one fewer decision at the keyboard, one fewer thing to argue about in review.
Go grew by subtraction. No exceptions. No inheritance. No
generics for a decade. No ternary. No while. No implicit
conversions. One code format, enforced by a tool. The designers kept
taking knobs off until there was less to argue about. That's the trick.
Go is the cleanest case of constraints as pedagogy we
have: rm/acc applied to a language.
Remove the clever option and you don't lose power. You lose the decision. The decision was the tax. Strip a function down to the Go shape and this is what remains:
// errors are values. you check them. that's it.
func ReadConfig(path string) (*Config, error) {
data, err := os.ReadFile(path)
if err != nil {
return nil, fmt.Errorf("read config %s: %w", path, err)
}
var c Config
if err := json.Unmarshal(data, &c); err != nil {
return nil, fmt.Errorf("parse config: %w", err)
}
return &c, nil
}No try/catch. No hidden path. The control flow is the source. Read top to bottom and you know what happens when the file is missing. That legibility is not an accident. It is what remains after the language kept saying no to anything that would hide the path.
Clever code is a loan against the next reader, usually you, six months later, wondering what idiot wrote it. Boring code pays cash. Slower to write, faster to live with. Go optimizes for the second number. That's the one that compounds. Staying small is the expensive path, not the lazy one — keeping a language simple takes more design than letting it grow.
Remove to accelerate. Fewer features, fewer ways to be wrong, fewer arguments, faster ships. The series below shows how Go does it and how to steal the discipline even if you're stuck somewhere else.
Start at Subtraction if you want the case from the ground up. Jump to Patterns if you already buy it and just want code to steal. The throughline does not change: every Go choice is a removal that accelerated. Boring code beats clever code. Clear is better than clever.
You see the same shape in real systems. Go — Why It's Fast makes the performance case; legibility is that same story from the other side. The codebases that survive under load read like Go: small interfaces, errors as values, no cleverness left to debug at 3am.