4 ms·

I'm curious to know if anyone who regularly uses Rust could speak to a theory I have on the language. I'm by no means an expert but I've dabbled enough to know

I'm curious to know if anyone who regularly uses Rust could speak to a theory I have on the language. I'm by no means an expert but I've dabbled enough to know Rust is I think going to be far more important to the world than it is already. I'm planning to dive back into it, but this time I'm going to attempt to do all of my programming in such a way so as to not require 'lifetime' semantics. Not 100% sure how easy it would be to do so, but the theory is that maybe writing code that needs lifetime semantics is an anti-pattern? Rust has just given us the tooling so we can confirm that the "style" we are already writing our code in adhere's to Rust's guarantees...

_-___________-_ 7y ago
Using Rust daily since ~2016 here. I'm assuming that by "writing code that needs lifetime semantics" you mean "writing code that needs explicit lifetimes", since all code in Rust has some lifetime semantics going on. If I've misunderstood then please clarify. Lifetimes are one tool in the toolbox, and using them is absolutely not an anti-pattern. Being able to define and use explicit lifetimes is a really powerful tool that allows you to safely share data in ways that can be tricky and error-prone to do in some other languages. For example, a deserialiser could be passed a reference to a buffer (&'a [u8]) and return a struct where some fields are &'a str which are just bytes borrowed from that buffer. You could then perhaps trim() them - returning another &'a str which just points to a smaller slice of that same buffer, and pass them off to other parts of your program - potentially even pass them to an async function that you await on, which could run in another thread - and the explicit lifetimes mean your code will fail to compile if the buffer can be dropped before the string is.
- unexaminedlife 7y ago
  You're right. I worded that ambiguously. Thanks for the feedback (all comments).
mikekchar 7y ago
I'm not a proficient Rust programmer yet, but the thing I've been finding is that previous programming experience often suggest solutions that require lifetimes. These solutions are often inappropriate. I think as one becomes more fluent in Rust oriented solutions, it will become more obvious that there is a better way to approach the problem. It's not so much that the use of a lifetime is indicative of poor code. It's more that due to lack of experience in the Rust way of doing it, you are more likely to reach for lifetime solutions that are inappropriate. Trying to avoid them at all cost as a novice seems like a good way of finding out where you absolutely need them (and, in my experience, there are definitely many such places). It sounds like a good exercise.
dodobirdlord 7y ago
Consider a function that takes two references and returns a reference. Which of the two input reference lifetimes does the lifetime of the returned reference live in? Trick question, the function returns a static lifetime reference to a constant. Is this an anti-pattern? There are many situations where this would be the most efficient implementation. The compiler can frequently elide lifetimes, it only needs them when it's ambiguous. Sometimes you need to pass two references and return a reference.
- unexaminedlife 7y ago
  I think the question for me (in this thought experiment) will be "what will the code look like if I try to avoid this?". And what are the repercussions? From a performance and/or readability / comprehension standpoint (or any other perspective).

_-___________-_ 7y ago

Using Rust daily since ~2016 here. I'm assuming that by "writing code that needs lifetime semantics" you mean "writing code that needs explicit lifetimes", since all code in Rust has some lifetime semantics going on. If I've misunderstood then please clarify. Lifetimes are one tool in the toolbox, and using them is absolutely not an anti-pattern. Being able to define and use explicit lifetimes is a really powerful tool that allows you to safely share data in ways that can be tricky and error-prone to do in some other languages. For example, a deserialiser could be passed a reference to a buffer (&'a [u8]) and return a struct where some fields are &'a str which are just bytes borrowed from that buffer. You could then perhaps trim() them - returning another &'a str which just points to a smaller slice of that same buffer, and pass them off to other parts of your program - potentially even pass them to an async function that you await on, which could run in another thread - and the explicit lifetimes mean your code will fail to compile if the buffer can be dropped before the string is.

unexaminedlife 7y ago
You're right. I worded that ambiguously. Thanks for the feedback (all comments).

mikekchar 7y ago

I'm not a proficient Rust programmer yet, but the thing I've been finding is that previous programming experience often suggest solutions that require lifetimes. These solutions are often inappropriate. I think as one becomes more fluent in Rust oriented solutions, it will become more obvious that there is a better way to approach the problem. It's not so much that the use of a lifetime is indicative of poor code. It's more that due to lack of experience in the Rust way of doing it, you are more likely to reach for lifetime solutions that are inappropriate. Trying to avoid them at all cost as a novice seems like a good way of finding out where you absolutely need them (and, in my experience, there are definitely many such places). It sounds like a good exercise.

dodobirdlord 7y ago

Consider a function that takes two references and returns a reference. Which of the two input reference lifetimes does the lifetime of the returned reference live in? Trick question, the function returns a static lifetime reference to a constant. Is this an anti-pattern? There are many situations where this would be the most efficient implementation. The compiler can frequently elide lifetimes, it only needs them when it's ambiguous. Sometimes you need to pass two references and return a reference.

unexaminedlife 7y ago
I think the question for me (in this thought experiment) will be "what will the code look like if I try to avoid this?". And what are the repercussions? From a performance and/or readability / comprehension standpoint (or any other perspective).