Does Go's comma-ok type assertion v, ok := x.(T) cost more at runtime than the single-value form?

## The two spellings A type assertion takes an interface value and asks about the concrete value stored inside it. Go gives it two spellings: ```go v := x.(T) // single-value form v, ok := x.(T) // comma-ok form ``` Both ask the runtime the same question: is the dynamic type inside `x` exactly `T` (or, when `T` is an interface type, does the dynamic type implement `T`)? Using one spelling rather than the other does not skip, weaken or reorder that check. What differs is the code the compiler emits for the *failure* path. - **Single-value form.** On a mismatch the runtime panics. The panic value is a `*runtime.TypeAssertionError`, which implements `error`, and its message names the static interface type, the dynamic type actually present and the type you asked for — for example `interface conversion: interface {} is string, not int`. If the interface value is nil there is no dynamic type at all, and the panic says the interface is nil. - **Comma-ok form.** On a mismatch `v` gets `T`'s zero value and `ok` is `false`. There is no panic, no error value to inspect and nothing allocated; the branch you write on `ok` is the whole error handling. ## Why neither is "the fast one" The cost of an assertion lives in the check, not in the number of results. For a concrete `T` the check is a comparison of the dynamic type against a type descriptor whose address the linker fixed at build time; the boolean of the comma-ok form is the flag that comparison already produced. The panicking form does not "prepare a panic" on the success path — it branches to a runtime call only when the comparison fails. So micro-optimising by reaching for the single-value form buys nothing measurable, while giving up the ability to handle a mismatch. There is one genuine cost difference in this area, and it is about the *target* type rather than the spelling: asserting to another interface type is a runtime question ("does this dynamic type have all of those methods?") rather than a single comparison. That is orthogonal to comma-ok. ## Choosing between them The useful rule is about who controls the dynamic type. - **You control it → single-value form is fine, and is a form of assertion.** You boxed the value yourself two lines earlier, or a preceding switch already narrowed it. A panic here reports a programmer error loudly; silently substituting a zero value would hide the bug and produce wrong output further downstream. - **Something outside controls it → comma-ok, or a type switch with a `default` arm.** Anything decoded, read from a queue, handed in by a caller you do not compile with, or delivered on a bus as `any` has an open set of dynamic types. A new producer ships a new event kind and your dispatcher meets a type it has never seen; that must be a logged, counted, possibly dead-lettered event, not a panic. ## The panic is worse than it looks in a dispatcher A panic unwinds only its own goroutine and then, if nothing recovers it, takes the whole program with it. `recover` works only when it is called directly by a function deferred by the *panicking* goroutine — a supervisor goroutine cannot catch a panic raised in a worker. A middleware that spawns a goroutine per message therefore needs its own deferred recover inside that goroutine if it wants to survive one bad message, and that recover is itself a decision: it converts a crash into a silently dropped message, which is why counting and logging the unhandled type matters more than the recover. ## What reviewers look for In a pull request the tell is a single-value assertion applied to a value that arrived from outside the package: `payload := msg.Body.(OrderCreated)` on a bus that also carries `OrderCancelled`. Ask for the comma-ok form or a type switch with a default arm, and ask what the default arm does — dropping unknown kinds silently is a different bug from crashing on them, and the team should choose deliberately.