Comparing two identical 1MB strings takes 1.3 milliseconds. Comparing two 'unique.Handle[string]' values takes 0.31 nanoseconds. That's 4.1 million times faster.

The 'unique' package: a standard library solution for value canonicalization (also called interning). This talk explores the problem it solves, how it works internally with GC-integrated weak pointers, and when you should (and shouldn't) reach for it.

Main idea: The 'unique' package solves two related problems—redundant memory allocations and expensive O(N) string comparisons—by storing only one copy of each distinct value and returning handles that compare in O(1) time via pointer equality.

Questions this talk answers:

- Why is string comparison expensive? Go strings are compared byte-by-byte. Two identical 1MB strings require scanning all 1 million bytes. With 'unique.Handle', the same comparison is a single pointer check: 0.31 nanoseconds vs 1.3 milliseconds.

- How does it avoid memory leaks? The package uses weak pointers internally. When no handles reference a value, it becomes eligible for garbage collection automatically. No manual cleanup required.

- When should I use it? High duplication rate (>30% repeated values), frequent comparisons, or memory pressure from redundant strings. Poor fit: unique values, short-lived data, or forgetting to store handles (defeating the purpose).

- What's the gotcha with pointer fields? Structs containing pointers compare pointer addresses, not pointed-to values. Two structs with '*string' fields pointing to equal strings but different addresses produce different handles.

Attendees will understand when interning helps vs. hurts (with benchmarks showing the crossover points), learn the internal weak pointer mechanism, and see how 'net/netip.Addr' uses 'unique' to efficiently represent IP addresses—the real-world case that motivated the package after a 10-year journey from Issue #5160.