When Generics

The Generic Data Structures lesson showed that genericity stayed inside the source across three lessons: the type parameter was either inferred or written explicitly in the declaration, but it never entered the value. The interfaces topic measured the exact opposite — the dynamic type was carried inside the value and could only be read by asking the value. This closing lesson places these two writings, and the interface contract standing between them, side by side by doing the same job three times: a total-area computation is built with the empty interface, with generics, and with an interface contract, and in all three, where the binding is built is counted.

This was the course’s third claim: generics and interfaces do the same job in two separate places. In generics the binding is built in the declaration and at the use site, it never enters the value; in an interface the binding enters the value. This lesson measures this difference for the first time by directly running it, writing the same computation three times.

The previous three lessons always measured generics on their own — never placed side by side with an interface. This left a debt in the course’s general framework: the claim “in generics the binding never enters the value” was, without a comparison being made, only an observation. This lesson closes that debt: the same job is written with both generics and an interface and measured in the same run, and the difference turns from a claim into a number (8 bytes against 16 bytes).

The Same Job, Three Writings

The job measured is simple: computing the total area of shapes in a collection. Square and Circle each carry their own Area() method; the Shape interface lists this single method. This job was chosen deliberately: the area computation genuinely varies by type — a square’s area is the side squared, a circle’s area is the radius squared times a constant — but the summing operation itself is the same for every type. The job all three writings have to accomplish therefore splits into two parts: the type-specific part (Area()’s own body) and the type-independent part (accumulating the total).

// three.go — the same job in three writings: empty interface, generics, interface contract
package main

import (
	"fmt"
	"unsafe"
)

type Square struct{ Side float64 }

func (s Square) Area() float64 { return s.Side * s.Side }

type Circle struct{ Radius float64 }

func (c Circle) Area() float64 { return 3.14159 * c.Radius * c.Radius }

type Shape interface{ Area() float64 }

// 1) with the empty interface: a type assertion (a type-switch branch) is needed for every element.
func totalAreaAny(s []any) (total float64, assertionCount int) {
	for _, e := range s {
		switch v := e.(type) {
		case Square:
			assertionCount++
			total += v.Area()
		case Circle:
			assertionCount++
			total += v.Area()
		}
	}
	return
}

// 2) with generics: the body is the same for every T, and as long as T stays homogeneous there is no type assertion at all.
func totalAreaGeneric[T Shape](s []T) (total float64) {
	for _, e := range s {
		total += e.Area()
	}
	return
}

// 3) with an interface contract: different concrete types in the same slice, no type assertion at all.
func totalAreaInterface(s []Shape) (total float64) {
	for _, e := range s {
		total += e.Area()
	}
	return
}

func main() {
	fmt.Println("-- same job, three writings --")

	mixed := []any{Square{Side: 2}, Circle{Radius: 1}, Square{Side: 3}}
	tAny, assertions := totalAreaAny(mixed)
	fmt.Printf("empty interface  total=%.4f  type assertions=%d  declaration lines=0\n", tAny, assertions)

	homogeneous := []Square{{Side: 2}, {Side: 3}}
	tGeneric := totalAreaGeneric(homogeneous)
	fmt.Printf("generic          total=%.4f  type assertions=0  declaration lines=1 (constraint)\n", tGeneric)

	contracted := []Shape{Square{Side: 2}, Circle{Radius: 1}, Square{Side: 3}}
	tInterface := totalAreaInterface(contracted)
	fmt.Printf("interface        total=%.4f  type assertions=0  declaration lines=1 (interface)\n", tInterface)

	fmt.Println()
	fmt.Println("-- limiting measurement: the gain disappears once T is pinned to an interface --")
	heterogeneous := []Shape{Square{Side: 2}, Circle{Radius: 1}}
	tDegenerate := totalAreaGeneric(heterogeneous)
	fmt.Printf("totalAreaGeneric[Square](homogeneous)   T=Square  element size=%d bytes  result=%.4f\n",
		unsafe.Sizeof(homogeneous[0]), tGeneric)
	fmt.Printf("totalAreaGeneric[Shape](heterogeneous)  T=Shape   element size=%d bytes  result=%.4f\n",
		unsafe.Sizeof(heterogeneous[0]), tDegenerate)
}

-- same job, three writings --
empty interface  total=16.1416  type assertions=3  declaration lines=0
generic          total=13.0000  type assertions=0  declaration lines=1 (constraint)
interface        total=16.1416  type assertions=0  declaration lines=1 (interface)

-- limiting measurement: the gain disappears once T is pinned to an interface --
totalAreaGeneric[Square](homogeneous)   T=Square  element size=8 bytes  result=13.0000
totalAreaGeneric[Shape](heterogeneous)  T=Shape   element size=16 bytes  result=7.1416

GE13. The first three lines compare three sources of the same computation. The empty interface writing runs a type assertion (a branch of the type switch) for all three of its three elements and declares no interface at all — the contract is written nowhere in the source, only the case branches inside the switch implicitly say which types are expected. The generic writing runs with zero type assertions, but homogeneous contains only Square — T, as the Generic Data Structures lesson measured, is pinned to a single concrete type in the caller’s own declaration. The interface writing also runs with zero type assertions, and moreover can carry Square and Circle in the same slice — contracted holds both at once, which homogeneous could not have held.

The Limiting Measurement: The Gain Disappears Once T Is Pinned to an Interface

GE14. The last two lines show the limit of genericity. Because totalAreaGeneric‘s constraint is a method list, it can also instantiate T with an interface type — totalAreaGeneric[Shape](heterogeneous) compiles and accepts Square and Circle in a mixed slice. But its cost is measured: with T=Square, every element is 8 bytes (just the Side field itself); with T=Shape, every element is 16 bytes — the sum of the type pointer and the data pointer an interface pair carries. Pinning T to an interface breaks genericity’s promise of zero cost: the code is now running something no different at all from totalAreaInterface, it has just hidden this behind a type parameter.

totalAreaGeneric’s body stayed letter-for-letter the same across both calls — the line for _, e := range s { total += e.Area() } changed for neither T=Square nor T=Shape. What changed was only what T was, and this change doubled the element size. This comes from the very definition of genericity: a generic body, from a single source, runs the same operation for every T it is instantiated with. With T=Square, this operation calls Square.Area() directly, with no extra layer at all; with T=Shape, the same operation now makes an indirect method call through an interface value — even though not a single line changed in the source, what happens at run time changes.

This gives a definite answer to the course’s question: generics do not always win. If a collection’s elements are all the same concrete type, and the operation performed on them is the same for every type, generics provide both zero type assertions and zero extra bytes. If the elements have to carry different concrete types — if behavior genuinely has to vary by type — two choices remain: pin T to an interface and give up genericity’s gain, or write an interface from the start. The second is the more honest writing, because the source already says what is going to happen — that more than one concrete type will sit in the same place. A generic body, by definition, stays the same for every T it is instantiated with; wanting it to behave differently for different Ts contradicts genericity itself.

Course Wrap-Up

Interfaces, Errors and Generics opened with a single question: in Go, a type satisfying an interface is never written anywhere at all — so where is this binding built? Thirteen lessons asked this question across three mechanisms: in interfaces (implicit satisfaction, the empty interface, type assertion, embedding, consumer-side definition), in error values (the error interface, sentinel errors, wrapping, panic), and in generics (the type parameter, the type constraint, generic data structures, and this lesson’s comparison of all three).

The first claim was confirmed: eight of sixteen bindings are carried inside the value, because a Go interface value is a pair — both a concrete type and data. The second claim was confirmed: four bindings are built at the use site, and the source never says anywhere at all that a type satisfies an interface. The third claim was run directly in this lesson: generics and interfaces do the same job in two separate places — in generics the binding stays in the declaration and at the use site, in an interface it enters the value — and this gain of generics disappears the moment the type parameter is pinned to an interface.

One of these three mechanisms, “use site,” carries a warning: the use site is where the compiler looks, not where the source points. The Generic Functions lesson proved this by asking the compiler directly — writing the source to a temporary package and reading only whether it passed; the Generic Data Structures and Type Constraints lessons used the same method. This difference between an indirect proof (only showing that a contract is not written in the source) and a direct proof (seeing, by running it, where the compiler stops) is part of the course’s own measurement discipline: if a lesson says “this is built at the use site,” it must either call the compiler and show where it stops, or explicitly write that the proof is indirect.

The course closes without overgeneralizing: these three mechanisms (declaration, use site, value) do not cover all of Go’s type system, they only classify the answers given to the single question these thirteen lessons asked — where is this binding built? The table below gathers these thirteen answers into a single row each.

The three mechanisms measured across the course ultimately reduce to a single habit: asking, while reading a source, “where is this binding built?” If a declaration line is searched for and found, the binding is there; if not, two places remain — either a binding the compiler builds at the use site (the only way to see this is to call the compiler), or a binding that can only be learned by asking the running value. Asking these three questions in order is a measurable way of separating what Go’s type system says in the source from what it does not, while reading it.

Summary

• The same total-area computation was built three ways: the empty interface required three type assertions, generics and the interface ran with zero type assertions.
• Generics stay zero-cost only when T is pinned to a single concrete type; once T is pinned to an interface, element size rises from 8 bytes to 16 bytes and the gain disappears.
• An interface is needed when behavior genuinely has to vary by type, because a generic body stays the same for every T it is instantiated with.
• Of the sixteen bindings measured across the course, four were built in the declaration, four at the use site, eight inside the value; this distribution classifies not Go’s type system, only the question these thirteen lessons asked.
• Generics and interfaces do the same job in two separate places: in generics the binding never enters the value at all, in an interface it does — and this difference is the measurable counterpart of when to choose which.