[swift-evolution] What about garbage collection?

[Jean-Denis Muys]

Based on this as the summary of arguments I read so far on this thread, I tend to increase my +1. Here is what I read:

- arguments regarding energy efficiency, memory efficiency, or more generally hardware limitations seem to me rather short-sighted, as in “640 KB or RAM should be enough for all times to come” (original design decision by IBM for the PC). Is Swift a language designed for todays hardware? Or is it supposed to outlast it a wee bit?

- arguments that say that managing [some aspect of] memory is good because it will lead to better programs could be equally be brought forward against any optimisation. With or without GC, with or without RC, you can expect many programmer to make bad design decisions for lack of understanding of the technology, hardware or software. I really question whether making the programmer responsible for managing the object graph is “essential”. This thread has claimed that, but not supported it.

- arguments claimed elsewhere as myths that have been debunked (better efficiency and predictability come to mind) in comparisons with state of the art GC systems.

- arguments that seem to me a bit disingenuous, such as blaming GC for Java’s failure on the desktop

- arguments which I am not competent enough to understand, e.g. the write and read barriers topic, on which I would like to get better educated


Of course some ideal would be a language where GC is an option. I am not sure whether that is possible, though the one argument I saw against that, namely that libraries would be compatible with one of the options only, can be solved with the fat binary idea. We used to have libraries compatible with both PowerPC and Intel processors. That sounds a lot more complex.

Overall, my opinion at this time is that precluding GC is too short sighted, and any decision made today should not be incompatible with the possible introduction of GC tomorrow. While RC is adequate, GC is better on the long run, simply because higher level constructs make [good] programmers more productive, and would be a good longer term goal. I have still to meet a more productive environment than what the Lisp machines proposed in the 90’s. While I do not claim that GC was responsible for that, it was certainly part of the deal. Or perhaps my memory is fading, making them better than they actually were, that’s possible too.

Jean-Denis


> On 10 Feb 2016, at 07:14, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Strong -1 for GC.
> 
> I think the advantages of ARC over GC as given by Chris, Joe and Dave with regards to energy efficiency, memory efficiency, caching behavior, predictability, value types with copy on write and declarative memory management on the object graph level are essential and indispensable. 
> 
> And yes, I see it as an advantage having to think about memory management dependencies on the object graph level and deciding how to break cycles. I think this leads to much cleaner object models.
> 
> -Thorsten 
>