The codebase that breaks the categories
You open a Go repository. The file structure is flat. No deep package hierarchies mimicking a directory tree. No src/main/java/com/example. You see a server.go file. It defines a Server struct. It has a Start method. You scroll down. There's a parseConfig function. No receiver. Just inputs and outputs. You open handler.go. It passes a function to http.HandleFunc. You look for a class hierarchy. You find none. You look for an extends keyword. You find none. You look for monads, functors, or a type system that infers your life choices. You find none.
Go doesn't force a paradigm. It gives you structs, methods, interfaces, and functions. You combine them. The language assumes you are smart enough to pick the right tool without a ceremony tax. The result is code that looks procedural, object-oriented, and functional all at once. That is not a bug. That is the design.
Paradigms as tools, not religion
Go is a multi-paradigm language, but that label hides the real story. Go prioritizes explicitness and composition over inheritance and abstraction layers. Procedural programming is the default. You write functions that take arguments and return results. This is the backbone of the language.
Object-oriented patterns exist, but they look different. There are no classes. There is no inheritance. You define a struct to hold data. You attach methods to that struct using a receiver. You define behavior contracts using interfaces. The compiler checks if a type satisfies an interface by looking at its methods. No implements keyword. This is structural typing.
Functional patterns are also present. Functions are first-class values. You can assign them to variables, pass them as arguments, and return them from other functions. Closures capture the environment. You can write higher-order functions. Go doesn't include a map or filter in the standard library by default, but you can write them in three lines. The community prefers explicit loops over hidden iteration because they are easier to debug.
Go uses composition instead of inheritance. You can embed a struct inside another struct. The outer struct inherits the methods of the inner struct. This is not inheritance. It is delegation. The compiler generates forwarding methods. You can override methods by defining a method with the same signature on the outer struct. This allows you to build complex types from simple parts. A Server can embed a Logger and a Config. It gets logging and configuration without a class hierarchy. This keeps the type system flat and predictable.
The community mantra is "accept interfaces, return structs." This keeps code flexible without the complexity of deep class hierarchies. When a function accepts an interface, callers can provide mocks or alternative implementations. When a function returns a struct, the implementation details are hidden. You can change the struct later without breaking callers.
Go has a formatter. It runs on save. It decides indentation. It decides braces. You don't argue about style. You argue about logic. This reduces cognitive load. When you read Go code, the formatting is identical across the ecosystem. Trust gofmt. Argue logic, not formatting.
Go doesn't care about your paradigm. It cares about your code being readable and correct.
The three styles in one package
Here's the three styles side-by-side. Go lets you define them in the same package without ceremony.
package main
// Add sums two integers.
// Procedural: simple function, no state.
func Add(a, b int) int {
return a + b
}
// User holds a name.
type User struct {
Name string
}
// Greet returns a greeting.
// OO: method attached to User via pointer receiver.
func (u *User) Greet() string {
return "Hello, " + u.Name
}
// MakeMultiplier returns a closure.
// Functional: function returning a function, capturing factor.
func MakeMultiplier(factor int) func(int) int {
return func(x int) int {
return x * factor
}
}
Calling them looks different, but the compiler treats them as valid Go.
func main() {
// Procedural: direct function call.
fmt.Println(Add(2, 3))
// OO: method call on a struct value.
fmt.Println(User{Name: "Bob"}.Greet())
// Functional: invoke the returned closure.
fmt.Println(MakeMultiplier(3)(4))
}
What the compiler actually does
The compiler treats these styles uniformly. A method is just a function with a hidden first parameter. When you define func (u *User) Greet(), the compiler sees a function that takes a *User as the first argument. When you call user.Greet(), the compiler rewrites it to Greet(&user). This is syntactic sugar. There is no virtual method table. Method dispatch is direct.
The receiver name is usually one or two letters matching the type. (b *Buffer), (s *Service). Not (this *Buffer). Not (self *Buffer). This keeps the code concise.
Interfaces work differently. An interface value holds a pointer to the concrete type and a pointer to a table of methods. When you assign a struct to an interface, the compiler checks if the struct has all the methods. If it does, the assignment succeeds. This allows for duck typing without the runtime cost of reflection. Interface satisfaction is implicit. This is powerful but can be confusing. You might satisfy an interface accidentally. You add a method to a struct, and suddenly it satisfies an interface you didn't know about. This can break code that relies on type assertions. Be careful with method names. Use unique names or scoped interfaces.
Closures allocate heap memory if they capture variables. If a closure references a local variable, the compiler moves that variable to the heap so it survives the function return. This is invisible to you, but it matters for performance. If you create millions of closures in a hot loop, the heap allocation adds up.
Capitalization controls visibility. Name is exported. name is unexported. There are no public or private keywords. This is a design choice. It forces you to think about the API surface. If you export a field, you lose control over invariants. Prefer methods over exported fields.
Interfaces are contracts. Structs are data. Functions are logic. Keep them separate.
Real code mixes everything
Real code mixes these styles. A service struct holds configuration. Methods operate on that configuration. Contexts flow through the call stack to handle cancellation. Callbacks allow customization without inheritance. Error handling is explicit. You check if err != nil after every operation. This is verbose. It is also clear. The unhappy path is visible. You cannot accidentally swallow an error.
Here's a service struct that takes a context and a callback.
package main
import (
"context"
"fmt"
"time"
)
// Service holds configuration.
type Service struct {
Timeout time.Duration
}
// Fetch simulates work.
// Convention: ctx is the first parameter.
// Functional: `process` is a callback passed as an argument.
func (s *Service) Fetch(ctx context.Context, process func([]byte) error) error {
select {
case <-ctx.Done():
return ctx.Err()
case <-time.After(s.Timeout):
return fmt.Errorf("timeout")
}
}
Usage combines the method call with an inline closure.
func main() {
svc := Service{Timeout: 1 * time.Second}
ctx := context.Background()
// OO call with a functional callback.
err := svc.Fetch(ctx, func(data []byte) error {
fmt.Println("Got data")
return nil
})
if err != nil {
fmt.Println("Failed:", err)
}
}
The context.Context always goes as the first parameter, conventionally named ctx. Functions that take a context must respect cancellation and deadlines. If the context is done, the function should return quickly. The if err != nil boilerplate is verbose by design. The community accepts it because it makes the unhappy path visible.
Context is plumbing. Run it through every long-lived call site.
Pitfalls and compiler traps
Go's flexibility has traps. You can define an interface with one method and satisfy it everywhere, leading to "interface pollution" where every type implements Stringer or Describer unnecessarily. Stick to small interfaces. One or two methods.
Closures capture variables by reference, not value. Before Go 1.22, capturing a loop variable in a goroutine or closure caused a classic bug where all goroutines saw the final value. The compiler now rejects this with loop variable captured by func literal to force you to be explicit. You must create a copy of the variable or use the new loop semantics.
Pointer receivers allow mutation but can cause aliasing bugs. Use value receivers for small structs that don't need mutation. The compiler won't stop you from passing a pointer to a large struct by value, but it will warn you about inefficiency in some linters. Don't pass a *string. Strings are already cheap to pass by value. Passing a pointer adds indirection without benefit.
Structs can have tags. Name string json:"name"``. Tags are metadata for reflection. They are not part of the type system. Use them for serialization or database mapping. Struct tags are a convention for tooling, not a language feature.
The underscore discards a value intentionally. result, _ := func(). This tells the reader you considered the second return value and chose to drop it. Use it sparingly with errors. Dropping an error without a comment is a code smell.
Goroutine leaks happen when the goroutine waits on a channel that never gets closed. Always have a cancellation path. The worst goroutine bug is the one that never logs.
If you try to pass a function with the wrong signature, the compiler rejects it with cannot use ... as .... If you forget to use a variable, you get declared and not used. If you forget to import a package, you get undefined: pkg. The compiler is strict. It catches mistakes early.
The worst bug is the one that never logs. Check your errors.
When to use what
Use a plain function when the logic depends only on its arguments and returns a result. Use a struct with methods when you need to group related data and operations, and the receiver name is one or two letters matching the type. Use an interface when you want to depend on behavior rather than a concrete implementation. Use a closure when you need to capture variables from the surrounding scope and pass that logic elsewhere. Use a pointer receiver when the method needs to mutate the struct or the struct is large enough that copying is expensive. Use a value receiver when the struct is small and the method should not modify the state. Use a single goroutine with a channel when you need to decouple producers and consumers. Use plain sequential code when you don't need concurrency: the simplest thing that works is usually the right thing.
Pick the simplest tool. Complexity is a debt you pay with interest.