[swift-evolution] What about garbage collection?

[Haravikk]

Just to add my thoughts, but I definitely don’t want garbage collection back; firstly because when Apple announced ARC for Objective-C, I couldn’t believe we hadn’t been using it all along, as it just seemed like such an obvious solution that makes garbage collection largely obsolete.

But more importantly, any time spent on supporting garbage collection is time that could be spent on making ARC even better, and really the only area where there is trouble right now is detecting cycles, but that’s a problem that should be solved by making the debugging and profiling tools as good as possible so that issues can be found and corrected with the right combination of weak references etc.

So a -1 from me. While some of the disadvantages might be valid, I think on the whole ARC is a better mechanism overall, and there may be other ways to address any of the issues it may have, which will be harder to do if the team has to dedicate time to a garbage collector.

> On 9 Feb 2016, at 06:01, Colin Cornaby via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I thought I’d add my opinion to this thread even though it’s been well covered in different posts, just to put more weight on the -1 argument…
> 
> I spend most my time dealing with performance sensitive code, and Swift’s predictability is a very strong pro for it against languages like Java. Java’s garbage collector provides too much uncertainty and instability to performance.
> 
> There certainly are tradeoffs. ARC won’t catch things like circular retain loops. But as mentioned, tagged pointers on the modern architecture take care of the retain/release overhead.
> 
> I’ll put it a different way that sums up why I felt the need to reply: ARC has it’s inconveniences, but moving to garbage collection would likely lead us to abandon any plans to adopt Swift for many of our performance sensitive projects. If someone solves the “pausing” problem in a garbage collected language I’d reconsider. But until then it would take Swift out of consideration for a lot of projects.
> 
>> On Feb 8, 2016, at 11:56 AM, Félix Cloutier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Has there been a garbage collection thread so far? I understand that reference counting vs. garbage collection can be a heated debate, but it might be relevant to have it.
>> 
>> It seems to me that the two principal upsides of reference counting are that destruction is (essentially) deterministic and performance is more easily predicted. However, it comes with many downsides:
>> 
>> object references are expensive to update
>> object references cannot be atomically updated
>> heap fragmentation
>> the closure capture syntax uses up an unreasonable amount of mindshare just because of [weak self]
>> 
>> Since Swift doesn't expose memory management operations outside of `autoreleasepool`, it seems to me that you could just drop in a garbage collector instead of reference counting and it would work (for most purposes).
>> 
>> Has a GC been considered at all?
>> 
>> Félix
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160209/53918278/attachment.html>