The universal container
You are writing a utility function that needs to accept a configuration value. Sometimes it is a string, sometimes a number, sometimes a nested map. You could write three separate functions. You could define a custom interface with a dozen methods. Or you could tell the compiler to stop asking questions and just take whatever you hand it. That is exactly what any does.
What the empty interface actually does
any is not a new type. It is a predeclared alias for interface{}. The empty interface has zero methods. In Go, a type satisfies an interface if it implements every method the interface declares. Since interface{} declares nothing, every single type in the language satisfies it automatically. Integers, structs, slices, channels, and even other interfaces all fit inside any. Think of it like a standardized shipping crate. The crate does not care whether it holds a laptop, a crate of oranges, or a bag of cement. It just provides a uniform container that the logistics system can route, stack, and track without knowing the contents.
The alias was added in Go 1.18 alongside generics. Before that, developers had to type interface{} everywhere. The language team realized the empty interface was so common that it deserved a shorter name. The alias exists purely for readability. The compiler treats any and interface{} as identical.
A minimal example
Here is the simplest way to use it. You declare a variable with the any type, assign a concrete value, and pass it around.
package main
import "fmt"
// PrintValue accepts any type and prints it.
// The parameter type is any, so the compiler allows any assignment.
func PrintValue(v any) {
// fmt.Println handles the empty interface internally.
// It uses reflection to format the value for output.
fmt.Println(v)
}
func main() {
// Assign an integer to an any variable.
// The compiler wraps the int in an interface value automatically.
var x any = 42
PrintValue(x)
// Reassign a string to the same variable.
// The underlying concrete type changes, but the variable type stays any.
x = "hello"
PrintValue(x)
}
How the compiler boxes your data
When you assign 42 to x, the compiler does not store a raw integer in the variable. It creates an interface value. An interface value is a two-word structure under the hood: a pointer to type information and a pointer to the actual data. The type information tells the runtime what the concrete type is. The data pointer points to the boxed value. When you reassign "hello", the compiler updates both words. The variable x still has the static type any, but the dynamic type inside it shifts from int to string.
This boxing happens automatically. You never see the two-word structure in normal code, but it explains why passing large structs through any carries a small allocation cost. The value must be copied to the heap so the interface data pointer can reference it. If the value already lives on the heap, the compiler reuses the pointer. If it lives on the stack, the compiler allocates heap memory and copies it. This is why you should avoid boxing large structs or slices into any inside tight loops. The garbage collector will have to clean up the temporary allocations.
Go developers follow a simple convention when working with interfaces: accept interfaces, return structs. When you design a function that needs flexibility, any is an acceptable parameter type. Returning any from a public API usually signals a design that is too vague. Concrete return types make documentation, static analysis, and tooling work better. If you find yourself returning any from a library function, consider whether a custom interface or a generic type parameter would make the contract clearer.
Realistic usage: configuration and event routing
Real code rarely just prints values. You usually need to inspect what is inside the box and act on it. A common pattern is a configuration loader that reads JSON or YAML and stores values in a map with any values. Another pattern is an event bus where different handlers receive payloads of unknown structure.
package main
import (
"fmt"
"log"
)
// LoadConfig simulates parsing a configuration file.
// It returns a map where values can be strings, numbers, or booleans.
func LoadConfig() map[string]any {
// Simulated parsed data.
// The map values are stored as any to preserve heterogeneous types.
return map[string]any{
"port": 8080,
"debug": true,
"hostname": "localhost",
}
}
// GetPort extracts the port number safely.
// It checks the dynamic type before using the value.
func GetPort(cfg map[string]any) int {
// Retrieve the raw value from the map.
raw, exists := cfg["port"]
if !exists {
// Return a sensible default when the key is missing.
return 80
}
// Assert the dynamic type to int.
// The comma-ok idiom prevents a panic if the type is wrong.
port, ok := raw.(int)
if !ok {
log.Printf("port is not an int, got %T", raw)
return 80
}
return port
}
func main() {
cfg := LoadConfig()
fmt.Println("Port:", GetPort(cfg))
}
When you need to handle multiple possible types, chained type assertions become noisy. Go provides a type switch that cleans up the control flow. A type switch evaluates the dynamic type once and routes execution to the matching case. The compiler can verify that you covered the necessary branches, and the syntax reads like a standard switch statement.
func DescribeValue(v any) string {
// Type switch inspects the dynamic type once.
// Each case extracts the value with the correct concrete type.
switch val := v.(type) {
case int:
// Handle integer values.
return fmt.Sprintf("number: %d", val)
case string:
// Handle string values.
return fmt.Sprintf("text: %s", val)
case bool:
// Handle boolean values.
return fmt.Sprintf("flag: %t", val)
default:
// Fallback for unhandled types.
return fmt.Sprintf("unknown type: %T", v)
}
}
Pitfalls and compiler guardrails
The empty interface removes compile-time type checking. That is the trade-off. If you try to call a method that does not exist on the underlying type, the compiler will not stop you. The program will crash at runtime with a panic. If you forget the comma-ok idiom during a type assertion and the types do not match, you get a panic: interface conversion: any is string, not int message. The compiler also enforces strict assignment rules. You cannot assign an any variable back to a concrete type without an explicit assertion. Try assigning x (typed as any) directly to a var y int and the compiler rejects it with cannot use x (variable of type any) as int value in assignment. You must prove to the compiler that the dynamic type matches the static type you want.
Another common trap is comparing any values with ==. The empty interface supports equality checks, but the rules are strict. Two interface values are equal only if their dynamic types are identical and their underlying values are equal. A float64 value of 1.0 is not equal to an int value of 1, even though they represent the same number. The type information is part of the comparison. If you need to compare values of unknown types, you will quickly run into invalid operation: operator == not defined on interface errors when the underlying type does not support equality, like slices or maps.
Zero values also behave predictably but can surprise newcomers. An any variable declared without assignment holds a nil interface value. A nil interface is different from an interface that wraps a nil pointer. If you assign a nil *string to an any variable, the interface is no longer nil. The type information points to *string, and the data pointer is nil. Equality checks and type assertions will treat them differently. The compiler will not warn you about this distinction. You have to track it yourself.
Go developers accept the verbosity of explicit type checks because it makes the unhappy path visible. The community convention favors if err != nil { return err } and val, ok := v.(Type) over silent failures or reflection-heavy code. Reflection works on any values, but it is slower and bypasses compile-time guarantees. Use reflection only when you are building a serialization library or a testing framework. For application code, stick to type switches and assertions.
When to reach for any
Use any when you are building a serialization library that must handle arbitrary JSON or YAML structures. Use any when you are writing a generic logging function that accepts values of unknown types for formatting. Use a type switch when you need to extract and process multiple known types from an any variable. Use generics with type parameters when you want to preserve compile-time type safety while writing reusable code. Use a custom interface when you only care about specific behavior rather than the underlying data structure. Use plain concrete types when the function only ever handles one kind of value.
The empty interface is an escape hatch, not a default. Box values only when the type truly cannot be known ahead of time. Unbox them as soon as possible.