Lifetimes and borrowing are very much a correctness thing and aren't just for tracking when memory is freed. While you won't have use-after-free issues in a GCed language, you will still have all the other problems of concurrent modification (data races) that they prevent. This is true even in single-threaded code, with problems like iterator invalidation.
Lifetime analysis matters a lot for way more than just garbage collection.
File handles, iterators, mutex guards, database transaction handles, session types, scoped threads, anything where ordering or mutual exclusivity matters.
Re:Was Rust Worth It?
by robertlagrant on Thursday October 26, 2023 @03:49PM
(#38030843)
I don't know about all of those, but Python's context managers and built in constructs handle most of those, I think?
Only in the most basic cases. If your handle has to be passed into another function or outlive the current scope of your function, the guardrails end.
Mutability is a big one for correctness. In Python, any function you pass any (non-primitive) object to might be mutated right out from under you and you have no idea it's happening. In Rust, you have to explicitly provide mutable references, or you need to hand over ownership, in which case you don't care if the callee mutates its argument, because you no longer have access to it.
Definitely not - mypy's pretty good these days, and lots of people use it.
> But Rust's type system goes beyond just data types - lifetimes are also a part of the type system. I don't know how you can tack that on to Python.
Well, Python's objects are generally garbage collected rather than explicitly destroyed, so I don't think it'd make sense to have lifetimes? They don't seem a correctness thing in the same way that types do.