Let’s talk about handling different types in Go. You’ll sometimes find yourself with a value and you’re not quite sure what it is. Maybe it came from a user, a file, or an external service. In a strictly typed language, that can feel tricky. Go gives us two main tools for this situation: type assertions and type switches. They let you ask a value, “What are you?” and then act accordingly. I use them to write code that’s both flexible and safe.

Think of an empty interface, interface{}, as a box. It can hold absolutely any value. When you have one of these boxes, a type assertion is your way of peeking inside to see if it holds a specific type. You’re asserting, “I think this is a string, let me check.”

The simplest form is direct: val := myVar.(string). This says, “I believe myVar holds a string; give me that string.” But if you’re wrong, your program will panic and stop. That’s not very graceful. We can do better.

The safe way uses a two-value assignment. You get the value and a boolean that tells you if the assertion was true.

func getID(value interface{}) {
    id, ok := value.(int)
    if !ok {
        fmt.Println("That wasn't an integer.")
        return
    }
    fmt.Printf("The ID is %d\n", id + 100)
}

This pattern is your first line of defense. Always check the ok boolean. It turns a potential crash into a manageable condition you can handle. I use this constantly when dealing with data from external APIs or unmarshalled JSON, where types aren’t guaranteed.

When you have several possible types to check, repeating if statements gets messy. This is where the type switch shines. It’s a clean, readable way to branch your logic based on type.

Here’s a practical example from something I built recently. I was processing incoming events from a message queue; they could be strings, numbers, or complex maps.

func processEvent(event interface{}) {
    switch e := event.(type) {
    case string:
        fmt.Println("Logging text event:", e)
        writeToLogFile(e)
    case int:
        fmt.Println("Received numeric code:", e)
        lookupCode(e)
    case map[string]interface{}:
        fmt.Println("Parsing structured event.")
        for k, v := range e {
            fmt.Printf("  Key: %s, Value: %v\n", k, v)
        }
    default:
        fmt.Printf("Cannot handle event of type: %T\n", e)
    }
}

The beauty here is that within each case, the variable e is already of the correct type. You don’t need to cast it again. It makes the code flow naturally.

You’re not limited to built-in types. Your own structs work perfectly in type switches. This is useful when you have different structs flowing through the same channel or function, but they need unique processing.

Imagine a simple billing system. You might have a Subscription and a OneTimePayment.

type Subscription struct {
    UserEmail string
    Plan      string
}

type OneTimePayment struct {
    InvoiceID string
    AmountCents int
}

func finalizeTransaction(tx interface{}) {
    switch transaction := tx.(type) {
    case Subscription:
        fmt.Printf("Activating %s plan for %s\n", transaction.Plan, transaction.UserEmail)
        activateUserAccess(transaction.UserEmail)
    case OneTimePayment:
        chargeAmount := float64(transaction.AmountCents) / 100.0
        fmt.Printf("Charging $%.2f for invoice %s\n", chargeAmount, transaction.InvoiceID)
        markInvoicePaid(transaction.InvoiceID)
    }
}

This approach can sometimes be an alternative to defining a large interface with many methods. If the behavior is completely different per type, a type switch can be more straightforward.

A powerful use of type assertions is checking for interfaces, not just concrete types. You can ask, “Do you have this method?” This allows you to discover capabilities at runtime.

Let’s say you have types that can render themselves, but it’s optional.

type Renderer interface {
    Render() string
}

type Widget struct{ ID int }
type Gadget struct{ Name string }

func (g Gadget) Render() string {
    return "Gadget: " + g.Name
}

func display(item interface{}) {
    if r, ok := item.(Renderer); ok {
        // It knows how to render itself!
        fmt.Println(r.Render())
    } else {
        // Provide a default display
        fmt.Printf("Item: %v\n", item)
    }
}

func main() {
    w := Widget{ID: 42}
    g := Gadget{Name: "Thingy"}

    display(w) // Output: Item: {42}
    display(g) // Output: Gadget: Thingy
}

Here, Gadget satisfies the Renderer interface, so the assertion succeeds, and we call its Render method. Widget does not, so we fall back to the default. This is a nice way to provide optional behavior.

When you unmarshal JSON into a map[string]interface{}, you end up with a collection of unknown types. Type assertions are essential to pull useful data out of that map.

Here’s a function that tries to safely extract a configuration value, providing a default if it’s missing or the wrong type.

func getConfigInt(config map[string]interface{}, key string, defaultValue int) int {
    rawValue, exists := config[key]
    if !exists {
        return defaultValue
    }

    // The JSON unmarshaler uses float64 for numbers
    if num, ok := rawValue.(float64); ok {
        return int(num)
    }

    // Sometimes it might come in as an integer
    if num, ok := rawValue.(int); ok {
        return num
    }

    // If it's a string, try to convert it
    if str, ok := rawValue.(string); ok {
        if parsedNum, err := strconv.Atoi(str); err == nil {
            return parsedNum
        }
    }

    fmt.Printf("Warning: Config key '%s' has unsupported type %T. Using default.\n", key, rawValue)
    return defaultValue
}

This pattern makes your config handling robust. It tries multiple reasonable type conversions before giving up and logging a warning.

While type switches are convenient, it’s worth thinking about their performance if you’re calling them in a very tight loop, thousands of times per second. A type switch is generally compiled into an efficient sequence of comparisons. However, if you have a stable set of types, defining a proper interface and using method calls is usually the most performant and idiomatic path.

Consider this: a type switch decides what to do at the moment it runs. An interface method call is decided when the code is compiled. The compiler can optimize the latter more.

// Using a type switch (dynamic dispatch)
func calculateTypeSwitch(val interface{}) float64 {
    switch v := val.(type) {
    case int:
        return float64(v) * 1.1
    case float64:
        return v * 1.1
    default:
        return 0.0
    }
}

// Using an interface (static dispatch)
type Calculator interface {
    Calculate() float64
}

type MyInt int
func (m MyInt) Calculate() float64 { return float64(m) * 1.1 }

type MyFloat float64
func (m MyFloat) Calculate() float64 { return float64(m) * 1.1 }

func calculateInterface(c Calculator) float64 {
    return c.Calculate()
}

The interface version is often cleaner if you control the types. Use type switches when you don’t control the incoming types, like when processing arbitrary data.

You can use type assertions to make your error handling more precise. Instead of just checking error strings, you can check for specific error types.

The standard library does this. os.IsNotExist(err) checks for a specific kind of filesystem error. You can build similar logic for your own error types.

type RateLimitError struct {
    RetryAfterSeconds int
    Message           string
}

func (e *RateLimitError) Error() string {
    return fmt.Sprintf("Rate limited. Retry after %d seconds. %s", e.RetryAfterSeconds, e.Message)
}

func handleAPIError(err error) {
    if rle, ok := err.(*RateLimitError); ok {
        // Special handling for rate limits
        fmt.Printf("Hit rate limit. Sleeping for %d seconds.\n", rle.RetryAfterSeconds)
        time.Sleep(time.Duration(rle.RetryAfterSeconds) * time.Second)
        retryRequest()
    } else if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
        // Handle any network timeout
        fmt.Println("Network timeout occurred.")
        backoffAndRetry()
    } else {
        // Generic error fallback
        fmt.Printf("Unhandled error: %v\n", err)
    }
}

This lets you create sophisticated error recovery logic. You can identify the exact problem and react appropriately, rather than just logging a generic failure.

Ultimately, these tools are about giving you control at the boundaries of your system—where unknown data enters. They bridge the world of strict types and dynamic data. My rule of thumb is simple: if I can use a concrete type or a well-defined interface, I do. I reach for type assertions and switches when I’m parsing, validating, or adapting external input. They are precise tools for specific jobs, and when used thoughtfully, they make Go code remarkably adaptable without sacrificing clarity.