When are two Go interface values equal with ==, and when does that comparison panic?

### The rule An interface value is a pair of a dynamic type and a value. Two interface values compare equal with `==` when: 1. their dynamic types are **identical**, and 2. the stored values are equal according to that type's equality. Both conditions, in that order. Two interface values holding different types are unequal without even looking at the values: ```go var a any = 1 var b any = int64(1) fmt.Println(a == b) // false: int and int64 are different dynamic types ``` This surprises people who expect numeric coercion. Interfaces do not coerce - the type half is part of the identity. Two interface values that are both empty are equal, which is exactly the `x == nil` case, and it is always safe. ### Mixed operands When one operand is an interface and the other is a concrete value, the concrete one is converted to the interface type first, and then the same rule applies. So `err == ErrNotFound` compares dynamic types and values; it is true only when the error holds the very same sentinel value. ### The runtime panic Go's compiler normally refuses to compile `==` on a type that is not comparable - slices, maps and functions. But when the values are hidden behind an interface, the compiler cannot know what will be inside, so it emits the comparison and the **runtime** checks: ```go var s1 any = []int{1} var s2 any = []int{1} fmt.Println(s1 == s2) // panics: comparing uncomparable type []int ``` The panic message names the offending dynamic type. It fires when the two dynamic types are identical and that type is uncomparable; if the types differ, the answer is already false and nothing panics. Comparing against `nil` never panics, because the nil side has no type to compare. The same trap hides in structs: a struct type is comparable only if all its fields are, so a struct with one `[]string` field is uncomparable and panics the same way once boxed in an interface. ### Where this bites in practice - **Map keys.** A `map[any]V` or `map[string]any` compared for equality relies on the same machinery. Inserting a key whose dynamic type is a slice panics at insert time. - **Error comparison.** Comparing errors with `==` is fine for sentinel values of comparable types, but a custom error type whose struct carries a slice field will panic if two of them are ever compared directly. - **Deduplication.** A set built as `map[any]struct{}` over values of unknown shape is a landmine; use a key derived from the value instead. - **Test assertions.** Hand-rolled equality over `any` values behaves differently from a deep-equality helper such as `reflect.DeepEqual`, which handles slices and maps without panicking. ### Choosing the safe alternative When the dynamic type is genuinely unknown and might be uncomparable, do not compare the interface. Options: - constrain the interface so only comparable implementations exist, and say so in the doc comment; - compare an explicit key extracted from the value, such as an identifier field or a canonical string form; - use `reflect.DeepEqual` when structural equality is what you actually want, accepting its cost and its different semantics for nil versus empty slices. ### Nilness and equality together The two ideas reinforce each other. `x == nil` is just the equality rule applied to the empty pair: it is true only when the left operand has no type and no value. An interface holding a nil pointer has a type, so it is unequal to nil - and it **is** equal to another interface holding a nil pointer of the same type, since both halves match. That last fact is occasionally useful: two typed nils of the same type do compare equal to each other. ### What an interviewer is listening for The phrase both halves, the concrete example of `int` versus `int64` being unequal, and the awareness that comparability is a runtime property once a value is inside an interface. Candidates who have been bitten usually mention the map-key case unprompted.