3 ms·

I'm curious to see how this turns out, but one thing I'm not sure I agree with is that lifetimes are confusing? I want to be clear here, it's been a few years

by olliej 3y ago

I'm curious to see how this turns out, but one thing I'm not sure I agree with is that lifetimes are confusing? I want to be clear here, it's been a few years since my job was coding in rust, but I found lifetimes to probably be among the easiest parts of rust to understand. Is the issue actually not understanding what lifetimes are, or just that people need to annotate them explicitly (which obviously other languages don't do[1])? The former seems surprising to me, the latter I could understand more readily due to the combination of the newness/novelty of explicitly annotating the lifetime, and also the ' prefix to lifetime names which I can imagine triggering a "that's weird looking" response when people first need them - I think I may have had that response at first, but it was fairly brief as it's just an initially new/novel syntax, and even now having the sigil prefix seems like a reasonable way to distinguish lifetimes from anything else, it's similar to why there's a * in generators in JS despite it not being strictly necessary for parsing or type checking. One thing that did just occur to me though is how many adopters of rust were coming from languages with entirely automatic lifetime management (GCs, etc) so having to think about object lifetimes at all is new? I realize I've mostly assumed people adopting rust have been C, C++, etc devs where thinking about such things is mandatory and continuous, but if there are lots of adopters from managed languages then maybe that's new. In that case though I don't think the issue is rust's lifetimes specifically in as much as it's just object lifetimes at all?[3] [1] Because they don't need to because of implicit lifetime management (GC, automatic refcounting[2], etc) or because their programming model is "what memory safety?" [2] Yes I know refcounting is technically GC, but this is comparison to scanning GCs [3] [this is an addition] I want to be clear, I am not critiquing devs who have come from managed languages for not being aware of lifetimes, this is literally just saying "if you're from a language where it's not a thing you have to think about, the entire concept may be new"

ComputerGuru 3y ago
> In that case though I don't think the issue is rust's lifetimes specifically in as much as it's just object lifetimes at all? A comment [0] in this very thread lends credence to this. [0]: https://news.ycombinator.com/item?id=39597296 https://news.ycombinator.com/item?id=39597296
cogman10 3y ago
> One thing that did just occur to me though is how many adopters of rust were coming from languages with entirely automatic lifetime management (GCs, etc) so having to think about object lifetimes at all is new? Maybe not "new" but something that's tedious once you've drank the GC koolaid. With C++ explicit lifetime annotation is never required. You are expected to just do it right and know how long something will live (RAII helps a lot here). With Rust, when you get into a situation where lifetimes are required, it can often feel really tedious to have to insert them everywhere. Especially when dealing with structs and fields on structs. Heck, some things in rust simply aren't possible (in safe rust) that are possible with C++. For example, a class with a pointer to itself. In C++'s case you'd say "Well of course this lives as long as itself does so we don't need to free it" In rust, you literally have to use an `unsafe` block to make such a construct. And, of course, in managed languages you wouldn't take a second thought to why something like this. This particularly rears it's ugly head when you come from a managed language and you want to do multithreading in rust. Rust's promise of "We can do safe multithreading" sounds REALLY nice, until you learn exactly what that entails. It may be safer, but it's not easier. C++ is easier to multithread than rust (perhaps not correctly) and it's a LOT easier to do correctly in managed languages.

by olliej 3y ago

ComputerGuru 3y ago

> In that case though I don't think the issue is rust's lifetimes specifically in as much as it's just object lifetimes at all? A comment [0] in this very thread lends credence to this. [0]: https://news.ycombinator.com/item?id=39597296 https://news.ycombinator.com/item?id=39597296

cogman10 3y ago

> One thing that did just occur to me though is how many adopters of rust were coming from languages with entirely automatic lifetime management (GCs, etc) so having to think about object lifetimes at all is new? Maybe not "new" but something that's tedious once you've drank the GC koolaid. With C++ explicit lifetime annotation is never required. You are expected to just do it right and know how long something will live (RAII helps a lot here). With Rust, when you get into a situation where lifetimes are required, it can often feel really tedious to have to insert them everywhere. Especially when dealing with structs and fields on structs. Heck, some things in rust simply aren't possible (in safe rust) that are possible with C++. For example, a class with a pointer to itself. In C++'s case you'd say "Well of course this lives as long as itself does so we don't need to free it" In rust, you literally have to use an `unsafe` block to make such a construct. And, of course, in managed languages you wouldn't take a second thought to why something like this. This particularly rears it's ugly head when you come from a managed language and you want to do multithreading in rust. Rust's promise of "We can do safe multithreading" sounds REALLY nice, until you learn exactly what that entails. It may be safer, but it's not easier. C++ is easier to multithread than rust (perhaps not correctly) and it's a LOT easier to do correctly in managed languages.