Challenge 3: What "Zero Runtime Cost" Actually Means — Possible Solution ==================================================================== When the same generic function — say, this chapter's largest — is called once with a slice of i32 and once with a slice of f64, the Rust compiler generates TWO ENTIRELY SEPARATE, fully concrete functions during compilation: something conceptually equivalent to a hand-written largest_i32(list: &[i32]) -> i32 and a hand-written largest_f64(list: &[f64]) -> f64, each containing the exact same logic but specialized to its own concrete type, with all generic-ness completely resolved away by the time the program actually runs. At runtime, calling largest with an i32 slice is executing plain, ordinary, non-generic machine code — indistinguishable in performance from code a programmer could have written by hand for that specific type, with the compiler even able to apply the SAME type-specific optimizations it would for hand-written code. CONTRAST WITH A DYNAMIC-DISPATCH-BASED ALTERNATIVE: a language (or a Rust feature like `dyn Trait`, used differently from this chapter's static generics) that instead resolves "which actual implementation to call" at RUNTIME needs some mechanism to look that decision up while the program is executing — typically a vtable (a table of function pointers) that gets consulted on every call, plus, depending on the approach, values may need to be boxed (heap-allocated and accessed through a pointer) rather than stored directly. Both of these — the vtable lookup and any extra heap allocation/indirection — cost real CPU cycles and memory EVERY TIME the function actually runs, which monomorphized generics simply never pay, because the "which type is this" question was already answered once and for all at compile time, not re-asked on every single call while the program is running.