4 ms·

It's pretty much the reason for segfaults and use-after-free issues (which manifest as either memory corruption or security vulns) in reasonably sized codebases

It's pretty much the reason for segfaults and use-after-free issues (which manifest as either memory corruption or security vulns) in reasonably sized codebases - without a good understanding of ownership, it's non-obvious when a pointer is supposed to become invalid, and if that doesn't match up with when the data is actually freed, you have an issue that's hard to track down later. If you're using a language with garbage collection, it's obviously not going to result in segfaults, but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea. More generally, if your object is stored in multiple places in your code, you have to remember to clean up all references to it properly, in all the different states your system can be in, and your compiler can't verify you're doing that correctly without a borrow checker.

JoelMcCracken 10y ago
Problems involving memory deallocation in the GC applications I've written seem to happen infrequently, certainly infrequently enough that it is one of the lowest items on my list of things I'd like to fix that cause problems in development. > but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea. Mostly I think this is sufficiently handled by not mutating shared state as a practice. However, since Rust has mutable borrows, it seems to me that you're still in danger of running into this.
- vertex-four 10y ago
  Mutable borrows are not shared - you can't touch the data elsewhere while it's borrowed mutably, and you can't get a mutable borrow while there's immutable borrows. Shared state is unfortunately a common affliction on large codebases, and if the language supports and even encourages it, it can be difficult to prevent it from happening as the codebase grows and customers want features that don't fit into the architecture wonderfully.
- int_19h 10y ago
  In higher-level languages, object lifetime is more than just whether the memory is there or not; it's also about whether the usual invariants apply. For example, in C#, you need to Dispose() objects that are logically no longer used, to have them properly cleaned up. Using an object after it's disposed typically results in an ObjectDisposedException. This isn't as bad as a segfault, but ultimately it's still a crashing bug in the app - and solving it requires figuring out who needs to call Dispose when - i.e. figuring out the lifetime.
richardwhiuk 10y ago
If you don't understand your object graph, then maintaining a large codebase is going to become very difficult. You'll get questions like 'who is responsible for updating this object' or 'who is responsible for notifying when X happens', or 'why does every object talk to every other object', or 'why does it work very slowly when there's a large number of objects'

JoelMcCracken 10y ago

Problems involving memory deallocation in the GC applications I've written seem to happen infrequently, certainly infrequently enough that it is one of the lowest items on my list of things I'd like to fix that cause problems in development. > but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea. Mostly I think this is sufficiently handled by not mutating shared state as a practice. However, since Rust has mutable borrows, it seems to me that you're still in danger of running into this.

vertex-four 10y ago
Mutable borrows are not shared - you can't touch the data elsewhere while it's borrowed mutably, and you can't get a mutable borrow while there's immutable borrows. Shared state is unfortunately a common affliction on large codebases, and if the language supports and even encourages it, it can be difficult to prevent it from happening as the codebase grows and customers want features that don't fit into the architecture wonderfully.
int_19h 10y ago
In higher-level languages, object lifetime is more than just whether the memory is there or not; it's also about whether the usual invariants apply. For example, in C#, you need to Dispose() objects that are logically no longer used, to have them properly cleaned up. Using an object after it's disposed typically results in an ObjectDisposedException. This isn't as bad as a segfault, but ultimately it's still a crashing bug in the app - and solving it requires figuring out who needs to call Dispose when - i.e. figuring out the lifetime.

richardwhiuk 10y ago

If you don't understand your object graph, then maintaining a large codebase is going to become very difficult. You'll get questions like 'who is responsible for updating this object' or 'who is responsible for notifying when X happens', or 'why does every object talk to every other object', or 'why does it work very slowly when there's a large number of objects'