3 ms·

It's been so long I can barely remember now but I'm pretty sure it was the lifetime propagation that got me... once one struct had it, every struct using that s

It's been so long I can barely remember now but I'm pretty sure it was the lifetime propagation that got me... once one struct had it, every struct using that struct needed one, then there was more than one lifetime and combining them (and establishing the rules of how the lifetimes related to each other) bent my brain out of shape. Rc<> let me sidestep all of that.

rcxdude 1y ago
Yeah, once you're putting lifetimes in structs you're liable to run into trouble. In general you only want to do that for structs which are not expected to have long or complicated lifetimes (i.e. if you're expecting it might be allocated on the heap, it's likely too complicated to be workable)
0x457 1y ago
Yeah, lifetime in structs are PITA. However, IMO using them is "the right choice" only in certain situations where performance hit from not using it is too much. I get why serde uses it, but notice who those don't get exposed to end user that much.
teaearlgraycold 1y ago
Any time I need to explicitly give a lifetime in a struct I use an Rc or some other container. I’ve been using rust casually for years and every time I try to appease the compiler with lifetimes I realize it’s not worth my time. If someone has a very ELI5 resource that will make me understand when and why to do this I’d appreciate it. IMO this is something that should just be handled by extra runtime code or a magically smarter compiler. Lifetime management feels like something that matters in a microcontroller or hyper-optimized setting, but never when I’m executing code on Apple Silicon for a random application. And yet the language makes simple GC ergonomically painful. I love the language but don’t really need all of that performance. I would gladly take a 1% hit to increment reference counts.
- zozbot234 1y ago
  You're on Apple Silicon, which is the preferred platform for Swift. That does exactly what you're asking for wrt. ARC, and is memory safe.
- dev_l1x_be 1y ago
  We have production systems, with ~10k Rust without lifetimes. Sometimes you can get away not using it.

rcxdude 1y ago

Yeah, once you're putting lifetimes in structs you're liable to run into trouble. In general you only want to do that for structs which are not expected to have long or complicated lifetimes (i.e. if you're expecting it might be allocated on the heap, it's likely too complicated to be workable)

0x457 1y ago

Yeah, lifetime in structs are PITA. However, IMO using them is "the right choice" only in certain situations where performance hit from not using it is too much. I get why serde uses it, but notice who those don't get exposed to end user that much.

teaearlgraycold 1y ago

Any time I need to explicitly give a lifetime in a struct I use an Rc or some other container. I’ve been using rust casually for years and every time I try to appease the compiler with lifetimes I realize it’s not worth my time. If someone has a very ELI5 resource that will make me understand when and why to do this I’d appreciate it. IMO this is something that should just be handled by extra runtime code or a magically smarter compiler. Lifetime management feels like something that matters in a microcontroller or hyper-optimized setting, but never when I’m executing code on Apple Silicon for a random application. And yet the language makes simple GC ergonomically painful. I love the language but don’t really need all of that performance. I would gladly take a 1% hit to increment reference counts.

zozbot234 1y ago
You're on Apple Silicon, which is the preferred platform for Swift. That does exactly what you're asking for wrt. ARC, and is memory safe.
dev_l1x_be 1y ago
We have production systems, with ~10k Rust without lifetimes. Sometimes you can get away not using it.