4 ms·

> 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 ir

> 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.

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.