4 ms·

A portion is not all. GC doesn't solve all resource leaks. It does solve the problem of lifetimes.

by zbobet2012 10y ago

vvanders 10y ago
It also doesn't solve all your lifetime issues. Do you know that the library you passed your object to didn't take a reference? With GC'd languages you say "I don't care" to the lifecycle question which can(and will in any moderately complex software) come back to bite you.
- zbobet2012 10y ago
  That's not a lifetime problem. The object is still appropriately alive if referenced. The lifetime in the GC and free sense simply means that while an object reference exists it should be valid. See http://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Realtime.html http://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Realt... for example. GC doesn't guarantee you won't have resource leaks (of which memory is one). It guarantees that when you no longer reference an object it will be freed and that while you have a reference its valid. That's the lifetime problem. The Rust docs call it the same thing for that matter...
  - jononor 10y ago
    Maybe not strictly lifetime problem, but the unexpectedly extended lifetime can cause problem. The caller switches which object it is working on and now the live object in the library is disconnected. Or, if it is mutable, changes could be done by the library at a time which break caller expectations. I've found that in GC'ed languages (like Python or JavaScript) not taking care of "lifetime", easily results in logic bugs. Better than crashes* - but still problematic. * Maybe not always better either. Not crashing may lead to silent data corruption. And obvious problems (like crash) tend to be fixed faster than subtle ones, in practice.
osd 10y ago
Garbage collection does not actually solve the problem of lifetimes. At least not in the gc'd languages I am intimately familiar (c#/java). I cannot comment on whether or not Go solves the problem of lifetimes because I don't know the language well enough, but I feel confident that if it does solve the problem, it is with garbage collection in conjunction with another concept
moosingin3space 10y ago
Only if you restrict your definition of "lifetimes" to include memory. That said, memory isn't necessarily the only resource regulated by a lifetime, and that's why I prefer non-GCed languages for most things.

A portion is not all. GC doesn't solve all resource leaks. It does solve the problem of lifetimes.

It also doesn't solve all your lifetime issues. Do you know that the library you passed your object to didn't take a reference? With GC'd languages you say "I don't care" to the lifecycle question which can(and will in any moderately complex software) come back to bite you.

zbobet2012 10y ago
That's not a lifetime problem. The object is still appropriately alive if referenced. The lifetime in the GC and free sense simply means that while an object reference exists it should be valid. See http://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Realtime.html http://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Realt... for example. GC doesn't guarantee you won't have resource leaks (of which memory is one). It guarantees that when you no longer reference an object it will be freed and that while you have a reference its valid. That's the lifetime problem. The Rust docs call it the same thing for that matter...
- jononor 10y ago
  Maybe not strictly lifetime problem, but the unexpectedly extended lifetime can cause problem. The caller switches which object it is working on and now the live object in the library is disconnected. Or, if it is mutable, changes could be done by the library at a time which break caller expectations. I've found that in GC'ed languages (like Python or JavaScript) not taking care of "lifetime", easily results in logic bugs. Better than crashes* - but still problematic. * Maybe not always better either. Not crashing may lead to silent data corruption. And obvious problems (like crash) tend to be fixed faster than subtle ones, in practice.

osd 10y ago

Garbage collection does not actually solve the problem of lifetimes. At least not in the gc'd languages I am intimately familiar (c#/java). I cannot comment on whether or not Go solves the problem of lifetimes because I don't know the language well enough, but I feel confident that if it does solve the problem, it is with garbage collection in conjunction with another concept

moosingin3space 10y ago

Only if you restrict your definition of "lifetimes" to include memory. That said, memory isn't necessarily the only resource regulated by a lifetime, and that's why I prefer non-GCed languages for most things.