> Part of the issue is just that Rust is actually very good at working out lifetimes in certain situations, so they become implicit. This makes it even harder

> Part of the issue is just that Rust is actually very good at working out lifetimes in certain situations, so they become implicit. This makes it even harder for the inexperienced to know when and why one has to specify a lifetime, as well as what the lifetime ought to be. What you refer to called lifetime elision, and there's an exact rule set [1] for that, so you will know exactly when lifetime are required, but you can always explicitly specify lifetime for every reference. About the why: lifetime is a tool for you to give a constraint to your function regarding lifetime of reference (and reference-based struct) of your input and output. My favorite example for introducing lifetime is: fn take_until<'a>(source: &'a str, token: &'_ str) -> &'a str { // take str from source until hit token } means that the output can not live longer than the first input, and it doesn't have to care about the lifetime of the second input. My mention regarding recursive is more about programming and related concepts (terminal conditions, tail recursion, avoid infinite recursion...) than math recursive. For math, I was so proud of myself when I first understood and solved a recursive induction proof. [1] https://doc.rust-lang.org/nomicon/lifetime-elision.html#lifetime-elision https://doc.rust-lang.org/nomicon/lifetime-elision.html#life...