3 ms·

I don't see how different syntax can have any impact on the understandability of lifetime. Imagine every usage of `'` will be replaced with a `lifetime` keyword

I don't see how different syntax can have any impact on the understandability of lifetime. Imagine every usage of `'` will be replaced with a `lifetime` keyword, `<'a>` becomes `<lifetime a>`, `&'a b` becomes `&lifetime a b`, I'd argue it would make the situation even worse. Lifetime in Rust is actually an explicit generic type system over lifetime is a new concept (you would not see it anywhere else) so it will indeed feel alien as you can't map it to other construct that you have already learned in other language. So to learn it you must treat it as such: a new concept, learn it by remember how you first learned recursive (yes, Rust's lifetime is not harder than recursive), pointers, ... Don't expect it to be easy or familiar because you already know how to code in other languages. I see many people struggle with learning Rust just because of this weird expectation that new language should be *very* similar and they do not have to spend much effort to understand.

bscphil 5y ago
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. The issue isn't so much that you can't map lifetimes onto a concept from another language so much as it is that you can't map the concept onto anything you already know at all. If you know what a function is (i.e. you've taken an algebra class required of all U.S. students), you can work out for yourself in 10 minutes how a recursive function works. It may be surprising at first that a recursive function can return a value (instead of just calling itself forever), but by examining a simple one (like nth Fibonacci) any student with an understanding of algebra can determine that it does. Incidentally, most high school students who progress as far as calculus meet with recursive functions like the following (though usually not expressed with this notation): f(x) = x/2 + f(x/2) I'd say the concept of a function is itself something new and extremely difficult (I remember finding the syntactic ambiguity between function notation and multiplication very confusing), but fortunately most students encounter it well before they ever try programming.
- unrealhoang 5y ago
  > 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...

bscphil 5y ago

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. The issue isn't so much that you can't map lifetimes onto a concept from another language so much as it is that you can't map the concept onto anything you already know at all. If you know what a function is (i.e. you've taken an algebra class required of all U.S. students), you can work out for yourself in 10 minutes how a recursive function works. It may be surprising at first that a recursive function can return a value (instead of just calling itself forever), but by examining a simple one (like nth Fibonacci) any student with an understanding of algebra can determine that it does. Incidentally, most high school students who progress as far as calculus meet with recursive functions like the following (though usually not expressed with this notation): f(x) = x/2 + f(x/2) I'd say the concept of a function is itself something new and extremely difficult (I remember finding the syntactic ambiguity between function notation and multiplication very confusing), but fortunately most students encounter it well before they ever try programming.

unrealhoang 5y ago
> 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...