Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Rust Lifetime Misconceptions (2020)

github.com

Post reply on HN
Print view View original

21–30 of 89 posts

Re: Common Rust Lifetime Misconceptions (2020)

#21

Post by BD103 »

ForkMeOnTinder wrote: post #15

About #10: > because to unify them at this point would be a breaking change Couldn't they change this in a future edition without breaking older editions?

Technically yes, but editions are more like different "flavors" of Rust than actual breaking changes. A 2021 crate is supposed to be able to import a 2018 crate, likewise for 2015 and 2024. Because they all need to work together, edition changes still need to be somewhat compatible with older versions.

Because you can pass closures into functions across crate boundaries, which requires consistent lifetime semantics, I find it unlikely that this will be implemented.

Re: Common Rust Lifetime Misconceptions (2020)

#22

Post by gadmm »

#9 (downgrading mut refs to shared refs) is a big one. It makes things quite a bit more complicated in the context of our work on the OCaml-Rust interface (more precisely the safe interface for the GC). As I understand it, this is not a sacrifice we make at the "Altar of Memory Safety", but one we make at the Altar of Mutex::get_mut and Cell::get_mut, which is a much smaller altar (how often do you find yourself in possession precisely of a mutable borrow of a Mutex or of a Cell?).

Re: Common Rust Lifetime Misconceptions (2020)

#23

Post by tadfisher »

ForkMeOnTinder wrote: post #15

About #10: > because to unify them at this point would be a breaking change Couldn't they change this in a future edition without breaking older editions?

A new edition is not a free pass to break source compatibility; it's more like a fire axe hidden behind breakable glass. You really, really want to avoid breaking changes because your users will now have to know about the difference between the compiler editions used by each of their projects.

In short, yes, but be very wary.

Re: Common Rust Lifetime Misconceptions (2020)

#24

Post by lmm »

inferiorhuman wrote: post #18
MuffinFlavored wrote: post #2

How I bail myself out of Rust lifetime problems as somebody who probably learned Rust the wrong way (by just trying to build stuff as if it were C/node.js and run into problems instead of slowing down + reading): 1. .clone() / .to_owned() 1. String -> vs &String/&str with & borrow 1. lazy_static / OnceCell + Lazy / OnceLock 1. Arc > with lots of .lock(). What would start off as like NULL in Java/C is Arc >> and you h…

I think there's a lot to be gained by not writing Rust like C, to the extent that it might be worth taking some time to pick up another language (maybe a lisp variant?) first. 2.) Be careful because &String is not &str, although in many cases you can pretend thanks to magic of AsRef/AsDeref. 4.) If you find yourself calling is_none, rethink things a bit. Pattern matching and the various destructuring (e.g. if let) fe…

> maybe a lisp variant?

Nah, go with an ML-family language. Maybe even Standard ML, because it will nudge you away from writing "C in ML" and encourage you to pick up the idiomatic way of doing things. (Laurence Paulson's book has an online version available for free on his homepage).

Re: Common Rust Lifetime Misconceptions (2020)

#25

Post by farmeroy »

MuffinFlavored wrote: post #2

How I bail myself out of Rust lifetime problems as somebody who probably learned Rust the wrong way (by just trying to build stuff as if it were C/node.js and run into problems instead of slowing down + reading): 1. .clone() / .to_owned() 1. String -> vs &String/&str with & borrow 1. lazy_static / OnceCell + Lazy / OnceLock 1. Arc > with lots of .lock(). What would start off as like NULL in Java/C is Arc >> and you h…

Once I started taking this advice, Rust became manageable to me! Currently, Trait Implementations have been more of a stumbling block for me than the borrow checker

Re: Common Rust Lifetime Misconceptions (2020)

#26

Post by farmeroy »

satvikpendem wrote: post #11

I just clone everywhere and write Rust like a high level language. Then, once I need to optimize more, if I ever do (as Rust is many times faster than other languages even with liberal cloning), then I simply go through and remove the clone where needed.

Me too. I also do this with .unwrap() - when I'm pretty sure of the happy path - while I'm prototyping. It's pretty easy afterwards to run back through and replace .unwrap() calls with better error handling. But as I improve, I'm getting more in the habit of using matching directly. Understanding lifetimes is probably really helpful for understanding library errors though and I need to go deeper there for sure

Re: Common Rust Lifetime Misconceptions (2020)

#28

Post by csjh »

andyferris wrote: post #27
almost_usual wrote: post #3

Once I discovered ‘static was the subtype of all lifetimes rather than the super things began clicking for me.

Could you elaborate? I find this unintuitive.

Since static lifetimes last for the entirety of the program, it can sub in for any other lifetime (as it is guaranteed to exist until the end of the other lifetime)

Re: Common Rust Lifetime Misconceptions (2020)

#29

Post by drewtato »

ForkMeOnTinder wrote: post #15

About #10: > because to unify them at this point would be a breaking change Couldn't they change this in a future edition without breaking older editions?

Most likely yes.

However, if you don't specify the argument type, it compiles fine. It's rare that you need to specify argument or return types on a closure, so it's not actually a large issue.

Re: Common Rust Lifetime Misconceptions (2020)

#30

Post by cwzwarich »

almost_usual wrote: post #3

Once I discovered ‘static was the subtype of all lifetimes rather than the super things began clicking for me.

`static is actually the superlifetime of all lifetimes, but & is contravariant in its lifetime parameter (and covariant in its type parameter).
Post reply on HN