The Secret Life of Go: Generics

Compile-Time Safety, Type Constraints, and When to Write Code Twice

#Golang #Generics #SoftwareEngineering #BackendDev

Eleanor is a senior software engineer. Ethan is her junior colleague. They work in a beautiful beaux arts library in Lower Manhattan — the kind of place where coding languages are discussed like poetry.

Episode 29

Ethan was staring at a stack trace that had just crashed his local testing environment.

panic: interface conversion: interface {} is string, not main.UserStruct

Eleanor walked by, pausing behind his chair. "A runtime panic. Let me guess: you pulled something out of the sync.Map we built yesterday and tried to cast it to the wrong type."

"I thought I was saving a User struct," Ethan sighed, rubbing his temples. "But somewhere else in the code, I accidentally saved the user's ID as a string under the same key. When I tried to pull it out and assert it as a User, the program blew up."

He leaned back. "You warned me that sync.Map uses any and drops type safety. But this feels like a step backward. Am I really supposed to just cross my fingers and hope I don't typo an interface assertion?"

"Before Go 1.18, yes. You had to rely on strict discipline and unit tests," Eleanor said, taking the seat next to him. "But today, we have a way to get the performance of a concurrent map and the safety of compile-time checks. We use Type Parameters. We use Generics."

The Type Parameter (`[K, V]`)

"Generics allow us to write code that works with multiple types, without sacrificing the compiler's ability to check our work," Eleanor explained. "We are going to wrap the sync.Map in a custom struct."

She opened a new file and typed:

// SafeCache wraps a sync.Map to provide compile-time type safety.
// We define two Type Parameters: K for the key, V for the value.
type SafeCache[K comparable, V any] struct {
    internal sync.Map
}

Ethan pointed at the square brackets. "What is comparable? Why isn't K just any?"

"A map key must be hashable so the map can look it up," Eleanor said. "You can't use a slice or a function as a map key. comparable is a built-in constraint. It tells the compiler: 'Only allow types here that can be compared using == and !='. The value V, however, can be absolutely anything."

The Generic Methods

Eleanor proceeded to write the methods for their new struct.

// Store saves a typed key and value into the internal map.
func (c *SafeCache[K, V]) Store(key K, value V) {
    c.internal.Store(key, value)
}

// Load retrieves a typed value.
func (c *SafeCache[K, V]) Load(key K) (V, bool) {
    val, ok := c.internal.Load(key)
    if !ok {
        var zero V // Create a zero-value of type V to return safely
        return zero, false
    }
    
    // We can safely type assert to V because Store() guarantees 
    // nothing else could have been saved!
    return val.(V), true 
}

Ethan's eyes lit up. He immediately refactored his calling code:

func main() {
    // We instantiate the generic struct with concrete types
    var userCache SafeCache[string, UserStruct]

    userCache.Store("user_1", UserStruct{Name: "Alice"})
    
    // ERROR: The compiler stops this immediately! 
    // userCache.Store("user_2", "just a string") 

    // No type assertion needed when loading!
    user, found := userCache.Load("user_1")
    if found {
        fmt.Println(user.Name)
    }
}

"Look at that," Ethan marveled. "I tried to save a string, and my IDE threw a red squiggly line before I even compiled. No more runtime panics. It caught the bug instantly."

"Exactly," Eleanor smiled. "You've hidden the dangerous any interface inside a strictly typed, generic wrapper."

The Architect's Constraint

Empowered by his new tool, Ethan opened up a utility file.

"I have this simple Add function," he said rapidly. "Right now, I have an AddInts(a, b int) and an AddFloats(a, b float64). It's so repetitive. I'm going to use Generics to combine them into one!"

He started typing out constraints, importing golang.org/x/exp/constraints to support mathematical operators.

"Stop," Eleanor said gently but firmly.

Ethan paused.

"Generics are a powerful architectural tool," Eleanor explained. "They are brilliant for data structures—like caches, trees, queues, and linked lists—where the logic of the structure has nothing to do with the data it holds. But they come with a cost. They make your code harder to read, and they increase compile times."

"But I have to write the same three-line function twice," Ethan argued.

"Yes. And you should," Eleanor replied. "There is a famous Go proverb: A little copying is better than a little dependency. Do not use Generics just to save yourself a few keystrokes. If the function is short, write it twice. Embrace the simplicity."

Ethan deleted his generic math function and looked back at his SafeCache. "Use Generics for complex data structures and algorithms. Use copy-paste for simple logic."

"Precisely," Eleanor said, closing her laptop. "Safety where you need it. Simplicity everywhere else."

Key Concepts

Type Parameters ([T any])

Generics use square brackets [] to declare type parameters, allowing functions and structs to operate on abstract types that are defined at instantiation.

Type Constraints

any: An alias for interface{}. Accepts any type.
comparable: A built-in constraint that restricts the type parameter to types that support the == and != operators (required for map keys).

The Generic Wrapper Pattern

A standard Go pattern for providing type safety over standard library tools that rely on any (like sync.Map or sync.Pool). The wrapper handles the dangerous type assertions internally, exposing a strictly typed API to the caller.

The Zero-Value Trick

When returning from a generic function upon failure, you cannot return nil because V might be a value type (like int). Instead, declare var zero V and return zero.

The Architectural Limit

Generics add cognitive load. They should be reserved for data structures (Lists, Sets, generic Caches) and complex algorithms (Sorting, Filtering). They should not be used merely to deduplicate trivial, three-line functions.

Aaron Rose is a software engineer and technology writer at tech-reader.blog. For explainer videos and podcasts, check out Tech-Reader YouTube channel.

Search This Blog

Tech-Reader.blog