3 ms·

To me, garbage collection is a hack, trying to workaround the fact that we don't know how to deal with ownership. This is something Rust and C++ get right (uniq

• jcranmer 11y ago
  The problem with memory management is that, in any large system, you invariably have a situation where multiple need to share ownership of a resource (think std::shared_ptr or Rusts' Rc<T>). And in large systems, such ownership graphs may form cycles. Now you can build systems that detect cycles who lack ownership outside of the cycle and break them. We call those systems garbage collectors.
• Aeolos 11y ago
  The thing is... std::shared_ptr is slower than a modern GC. It also doesn't protect you from memory fragmentation. GC is indeed a hack: it approximates an infinite memory system on systems that have finite memory. Reference counting is a worse hack: it approximates a GC on languages/systems that can't afford a real GC.
• gpderetta 11y ago
  GC is not an hack. Short of designing your language around ownership (like rust, Cyclone), it is the only way to guarantee memory safety, which is a fundamental property for a programming language. The automatic memory management part is almost just a nice bonus on top of that. And I say this as a C++ programmer that has written very little code on GC'd languages.
• theseoafs 11y ago
  > To me, garbage collection is a hack, trying to workaround the fact that we don't know how to deal with ownership. Eh. Often the whole "ownership" thing is irrelevant. For a lot of high-level programs, trying to express things in a Rust-ish "ownership" style with pointers adds a lot of syntactic and semantic overhead.
  • danieldk 11y ago
    Often the whole "ownership" thing is irrelevant. I don't see how it can ever be irrelevant, unless you use immutable data structures everywhere. Does your class/struct provide getters? Ownership! You have to think about what you return. When you are not careful, the calling code can break invariants of the data structure. Consider the following Go code: type Foo struct { sortedSlice []Bar // .... } func (f *Foo) sorted() []Bar { return f.sortSlice // Outside world can break invariants. } Now the outside world has access to internal state and can break invariants (make sortedSlice unsorted). You have to decide to: make a copy (and waste time) or document this fact (and put the burden on the user of Foo). Suddenly, knowing from the signature what the ownership is and having the compiler fail on violations, looks pretty useful! Tony Hoare once called the null pointer his one billion dollar mistake. I think the lack of ownership semantics (or immutability) is an even bigger mistake. Some of the most difficult and aggravating bugs that I encountered (even in relatively simple web services) were caused by (a lack of understanding of) ownership. Throw in some concurrency and you have bugs that occur frequently, but are terribly hard to reproduce consistently.
  • petke 11y ago
    Garbage collection only works well for memory though. Other resources like file handles, mutexes, database connections, etc. You don't want to leave those hanging. You want them to be released at once a scope is exited.
• im2w1l 11y ago
  >a rogue thread randomly scanning your memory for things that look like addresses. How does that avoid race conditions? What happens if I quickly move my pointer around? i.e. b=a;a=null;c=b;b=null;d=c... etc
  • Aeolos 11y ago
    It still works correctly. Try it.
• fsloth 11y ago
  "To me, garbage collection is a hack," Garbage collection trades the problems gc brings with less program complexity and programmer time. It's a degree of freedom that one can choose (if one can choose the language one uses). "Reserve memory for this entity when I declare it and release it when I don't seem to be using anymore" is huge leap in getting computers to assist us in our tasks. But sure, there are lot of problems domains where this is not a good thing.