While working on a generic function in Go, I once encountered this error: ‘incomparable types in type set’. It led me to dig deeper into the comparable constraint - a seemingly straightforward feature that has profound implications for Go’s generics. This wasn’t my first brush with generics, but it highlighted an important nuance that’s often overlooked. It’s basic, yet surprisingly intuitive and an overlooked facet of Go generics that can save you from unnecessary debugging and potential runtime errors. With this short post, I’ll walk you through what comparable is, why it’s useful and how you can leverage it for cleaner, type-safe Go code. If you’re a beginner or even a early mid-level Gopher, this is for you. Why comparable? Go’s type system is famously simple and strict. But when generics entered the scene with Go 1.18, we gained new tools to write reusable, type-safe code. Alongside the introduction of any (an alias for interface{}), we got comparable. So, what’s the deal? Simply put, comparable is a constraint that ensures a type supports equality comparisons (== and !=). In Go, only certain types are inherently comparable; these include primitive types like int, float64 and string, but exclude types like slices, maps and functions. This is because slices and maps are reference types, meaning their equality cannot be determined by their contents but rather by their memory addresses. Functions, on the other hand, represent pointers to code blocks and are generally incomparable for practical purposes. By enforcing the comparable constraint, Go helps ensure that generic functions relying on equality checks don't accidentally allow non-comparable types, preventing hard-to-debug runtime errors. Think of it as a guardrail for writing generic functions or types that rely on comparing values. Let’s say you want to write a generic function to check if a slice contains a specific value. Without comparable, you might inadvertently allow types like slices or maps, which are inherently not comparable in Go. The result? A compiler error when you try to use == on those types. With comparable, you can enforce at compile time that only valid, comparable types are used. This is incredibly valuable because it eliminates a whole class of runtime errors - like trying to compare slices or maps - before your code even runs. Compile-time checks provide immediate feedback, allowing you to fix issues early and ensuring that your functions behave predictably with the types they’re designed to handle. In a language like Go that emphasizes simplicity and reliability, this kind of safeguard aligns perfectly with the core philosophy of letting the compiler do the hard work for you. Here’s an example: type Array[T comparable] struct {
	data []T
}

func (a *Array[T]) Contains(value T) bool {
	for _, v := range a.data {
		if v == value {
			return true
		}
	}
	return false
}

func main() {
	arr := Array[int]{data: []int{1, 2, 3, 4, 5}}
	fmt.Println(arr.Contains(3)) // Output: true
	fmt.Println(arr.Contains(10)) // Output: false
} Try using a slice or a map as the type parameter and the compiler will immediately stop you in your tracks. This guardrail is what makes comparable a comparable! any vs. interface{}: Another player in the Go generics ecosystem is any, which is simply an alias for interface{}. Historically, interface{} has been a cornerstone of Go for representing any type, but its usage often confused newcomers due to its less intuitive name in the context of generics. The introduction of any with Go 1.18 aimed to simplify this by providing a more semantic alias, making it immediately clear that the type accepts ‘any’ value. While functionally identical to interface{}, any better aligns with the intentions of generics and improves readability, especially in generic function signatures. Consider this: func PrintValues[T any](values []T) {
	for _, v := range values {
		fmt.Println(v)
	}
} Here, using any makes it clear that the function works with any type, without implying additional constraints. Compare this to: func PrintValues[T interface{}](values []T) {
	// Same functionality, but less intuitive for generics
} While interface{} still works, any feels more natural in the context of generics. It’s a subtle shift, but one that makes your code more approachable; especially for newcomers. Real-World Scenarios: When to Use comparable and any 1. Deduplication with comparable Here’s a quick example of using comparable to remove duplicates from a slice: func RemoveDuplicates[T comparable](input []T) []T {
	seen := make(map[T]bool)
	result := []T{}

	for _, v := range input {
		if !seen[v] {
			seen[v] = true
			result = append(result, v)
		}
	}
	return result
}

func main() {
	fmt.Println(RemoveDuplicates([]int{1, 2, 2, 3, 4, 4}))
	// Output: [1 2 3 4]

	fmt.Println(RemoveDuplicates([]string{"go", "go", "lang"}))
	// Output: [go lang]
} 2. Flexible Utilities with any Use any for functions that don’t rely on constraints. For instance, a simple utility to print all elements in a slice: func PrintAll[T any](items []T) {
	for _, item := range items {
		fmt.Println(item)
	}
}

func main() {
	PrintAll([]int{1, 2, 3})
	PrintAll([]string{"hello", "world"})
} No constraints are needed here and any signals that the function is open to all types. Common Pitfalls 1. Trying to Compare Non-Comparable Types If you’ve ever tried this: arr := Array[[]int]{data: [][]int{{1, 2}, {3, 4}}}
fmt.Println(arr.Contains([]int{1, 2})) // Compiler error You’ll get a compilation error because slices are not comparable. A workaround? Wrap your slices in a struct with a custom Equals method or use a hash function for comparison. 2. Misusing any Avoid overusing any when a constraint would make your code safer. For example, consider a function to find the maximum value in a slice: func FindMax[T any](items []T) T {
    max := items[0]
    for _, item := range items {
        if item > max {
            max = item
        }
    }
    return max
} This code will fail to compile because any does not imply the ability to compare items using >. Instead, using T comparable ensures that the function can safely handle only types that support comparison: func FindMax[T comparable](items []T) T {
    max := items[0]
    for _, item := range items {
        if item > max {
            max = item
        }
    }
    return max
} By adding the comparable constraint, you not only fix the compilation issue but also make the function’s intent and requirements clear to anyone using it. Wrapping Up Whether you’re searching for a value, deduplicating a slice, or building your own generic utilities, understanding comparable can save you from unexpected bugs and runtime errors. So, next time you find yourself scratching your head over an ‘incomparable types’ error, remember: it’s not you - it’s Go, nudging you toward better design (as always :P ). And if you’re still unsure? That’s fine too. Learning the quirks of a language is part of the fun (and frustration) of being a developer. Thanks for your time! May the code be with you! My Social Links: LinkedIn | GitHub | 𝕏 (formerly Twitter) | Substack | Dev.to | Reddit While working on a generic function in Go, I once encountered this error: ‘incomparable types in type set’ . ‘incomparable types in type set’ It led me to dig deeper into the comparable constraint - a seemingly straightforward feature that has profound implications for Go’s generics. This wasn’t my first brush with generics, but it highlighted an important nuance that’s often overlooked. It’s basic, yet surprisingly intuitive and an overlooked facet of Go generics that can save you from unnecessary debugging and potential runtime errors. comparable With this short post, I’ll walk you through what comparable is, why it’s useful and how you can leverage it for cleaner, type-safe Go code. If you’re a beginner or even a early mid-level Gopher, this is for you. comparable Why comparable ? comparable Go’s type system is famously simple and strict. But when generics entered the scene with Go 1.18, we gained new tools to write reusable, type-safe code. Alongside the introduction of any (an alias for interface{} ), we got comparable . So, what’s the deal? any interface{} comparable Simply put, comparable is a constraint that ensures a type supports equality comparisons ( == and != ). comparable == != In Go, only certain types are inherently comparable; these include primitive types like int , float64 and string , but exclude types like slices, maps and functions. This is because slices and maps are reference types, meaning their equality cannot be determined by their contents but rather by their memory addresses. Functions, on the other hand, represent pointers to code blocks and are generally incomparable for practical purposes. int float64 string By enforcing the comparable constraint, Go helps ensure that generic functions relying on equality checks don't accidentally allow non-comparable types, preventing hard-to-debug runtime errors. Think of it as a guardrail for writing generic functions or types that rely on comparing values. comparable Let’s say you want to write a generic function to check if a slice contains a specific value. Without comparable , you might inadvertently allow types like slices or maps, which are inherently not comparable in Go. comparable The result? A compiler error when you try to use == on those types. == With comparable , you can enforce at compile time that only valid, comparable types are used. This is incredibly valuable because it eliminates a whole class of runtime errors - like trying to compare slices or maps - before your code even runs. Compile-time checks provide immediate feedback, allowing you to fix issues early and ensuring that your functions behave predictably with the types they’re designed to handle. comparable In a language like Go that emphasizes simplicity and reliability, this kind of safeguard aligns perfectly with the core philosophy of letting the compiler do the hard work for you. In a language like Go that emphasizes simplicity and reliability, this kind of safeguard aligns perfectly with the core philosophy of letting the compiler do the hard work for you . letting the compiler do the hard work for you Here’s an example: type Array[T comparable] struct {
	data []T
}

func (a *Array[T]) Contains(value T) bool {
	for _, v := range a.data {
		if v == value {
			return true
		}
	}
	return false
}

func main() {
	arr := Array[int]{data: []int{1, 2, 3, 4, 5}}
	fmt.Println(arr.Contains(3)) // Output: true
	fmt.Println(arr.Contains(10)) // Output: false
} type Array[T comparable] struct {
	data []T
}

func (a *Array[T]) Contains(value T) bool {
	for _, v := range a.data {
		if v == value {
			return true
		}
	}
	return false
}

func main() {
	arr := Array[int]{data: []int{1, 2, 3, 4, 5}}
	fmt.Println(arr.Contains(3)) // Output: true
	fmt.Println(arr.Contains(10)) // Output: false
} Try using a slice or a map as the type parameter and the compiler will immediately stop you in your tracks. This guardrail is what makes comparable a comparable! comparable any vs. interface{} : any interface{} Another player in the Go generics ecosystem is any , which is simply an alias for interface{} . Historically, interface{} has been a cornerstone of Go for representing any type, but its usage often confused newcomers due to its less intuitive name in the context of generics. any interface{} interface{} The introduction of any with Go 1.18 aimed to simplify this by providing a more semantic alias, making it immediately clear that the type accepts ‘any’ value. While functionally identical to interface{} , any better aligns with the intentions of generics and improves readability, especially in generic function signatures. any interface{} any Consider this: func PrintValues[T any](values []T) {
	for _, v := range values {
		fmt.Println(v)
	}
} func PrintValues[T any](values []T) {
	for _, v := range values {
		fmt.Println(v)
	}
} Here, using any makes it clear that the function works with any type, without implying additional constraints. any any Compare this to: func PrintValues[T interface{}](values []T) {
	// Same functionality, but less intuitive for generics
} func PrintValues[T interface{}](values []T) {
	// Same functionality, but less intuitive for generics
} While interface{} still works, any feels more natural in the context of generics. It’s a subtle shift, but one that makes your code more approachable; especially for newcomers. interface{} any Real-World Scenarios: When to Use comparable and any comparable any 1. Deduplication with comparable comparable Here’s a quick example of using comparable to remove duplicates from a slice: comparable func RemoveDuplicates[T comparable](input []T) []T {
	seen := make(map[T]bool)
	result := []T{}

	for _, v := range input {
		if !seen[v] {
			seen[v] = true
			result = append(result, v)
		}
	}
	return result
}

func main() {
	fmt.Println(RemoveDuplicates([]int{1, 2, 2, 3, 4, 4}))
	// Output: [1 2 3 4]

	fmt.Println(RemoveDuplicates([]string{"go", "go", "lang"}))
	// Output: [go lang]
} func RemoveDuplicates[T comparable](input []T) []T {
	seen := make(map[T]bool)
	result := []T{}

	for _, v := range input {
		if !seen[v] {
			seen[v] = true
			result = append(result, v)
		}
	}
	return result
}

func main() {
	fmt.Println(RemoveDuplicates([]int{1, 2, 2, 3, 4, 4}))
	// Output: [1 2 3 4]

	fmt.Println(RemoveDuplicates([]string{"go", "go", "lang"}))
	// Output: [go lang]
} 2. Flexible Utilities with any any Use any for functions that don’t rely on constraints. For instance, a simple utility to print all elements in a slice: any func PrintAll[T any](items []T) {
	for _, item := range items {
		fmt.Println(item)
	}
}

func main() {
	PrintAll([]int{1, 2, 3})
	PrintAll([]string{"hello", "world"})
} func PrintAll[T any](items []T) {
	for _, item := range items {
		fmt.Println(item)
	}
}

func main() {
	PrintAll([]int{1, 2, 3})
	PrintAll([]string{"hello", "world"})
} No constraints are needed here and any signals that the function is open to all types. any Common Pitfalls 1. Trying to Compare Non-Comparable Types If you’ve ever tried this: arr := Array[[]int]{data: [][]int{{1, 2}, {3, 4}}}
fmt.Println(arr.Contains([]int{1, 2})) // Compiler error arr := Array[[]int]{data: [][]int{{1, 2}, {3, 4}}}
fmt.Println(arr.Contains([]int{1, 2})) // Compiler error You’ll get a compilation error because slices are not comparable. A workaround? Wrap your slices in a struct with a custom Equals method or use a hash function for comparison. Equals 2. Misusing any any Avoid overusing any when a constraint would make your code safer. For example, consider a function to find the maximum value in a slice: any func FindMax[T any](items []T) T {
    max := items[0]
    for _, item := range items {
        if item > max {
            max = item
        }
    }
    return max
} func FindMax[T any](items []T) T {
    max := items[0]
    for _, item := range items {
        if item > max {
            max = item
        }
    }
    return max
} This code will fail to compile because any does not imply the ability to compare items using > . Instead, using T comparable ensures that the function can safely handle only types that support comparison: any > T comparable func FindMax[T comparable](items []T) T {
    max := items[0]
    for _, item := range items {
        if item > max {
            max = item
        }
    }
    return max
} func FindMax[T comparable](items []T) T {
    max := items[0]
    for _, item := range items {
        if item > max {
            max = item
        }
    }
    return max
} By adding the comparable constraint, you not only fix the compilation issue but also make the function’s intent and requirements clear to anyone using it. comparable Wrapping Up Whether you’re searching for a value, deduplicating a slice, or building your own generic utilities, understanding comparable can save you from unexpected bugs and runtime errors. comparable So, next time you find yourself scratching your head over an ‘incomparable types’ error, remember: it’s not you - it’s Go, nudging you toward better design (as always :P ). And if you’re still unsure? That’s fine too. Learning the quirks of a language is part of the fun (and frustration) of being a developer. Thanks for your time! May the code be with you! My Social Links: LinkedIn | GitHub | 𝕏 (formerly Twitter) | Substack | Dev.to | Reddit My Social Links: My Social Links: LinkedIn GitHub 𝕏 (formerly Twitter) Substack Dev.to Reddit

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Why ‘Incomparable Types’ in Go Are More Than Just a Compiler Error

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Checking Palindrome With Generics in Go 1.18

Generalized type constraints

Generic Programming in Go

Generics on Go’s stdlib

Improving your experience with Criteria API using Builder pattern and JPA Static Metamodel - Part II

Checking Palindrome With Generics in Go 1.18

Generalized type constraints

Generic Programming in Go

Generics on Go’s stdlib

Improving your experience with Criteria API using Builder pattern and JPA Static Metamodel - Part II

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps