> - Reference counting is a bad compromise between the unpredictability of GC, and the burden of explicit memory management. It's mostly unobtrusive, but I've s

> - Reference counting is a bad compromise between the unpredictability of GC, and the burden of explicit memory management. It's mostly unobtrusive, but I've seen examples of code that require careful and non-obvious use of weak to avoid memory leaks, (sorry, I don't have the reference handy). This is such a bizarre statement to me. I have to wonder if the commenter has ever dealt with production systems or code that uses GC? Because with years of writing and tuning Java servers, I've long since come to the conclusion that GC is largely a false economy. You still have to deal with memory leaks but the cause this time is objects maintaining references they don't need. Sure GCs become cleverer at detecting unused forests of objects and so on but this largely makes another problem worse: so-called stop-the-world pauses for a full GC. It's still an issue you have to deal with on Java, Go and probably every GC language. This isn't to say that ref-counting is a panacea (what is?). Particularly on servers the critical region for updating the ref-count itself can become hot and a bottleneck. But this isn't really a problem on mobile app code. I've long said that iOS's uses of ref-counting (ARC since 5.0+) is a strategic and competitive advantage to Android's Dalvik/Java GC. Google's Plan9 2.0 (ie Fuchsia) makes me sad (for many reasons). Just one is that they've embraced Dart/Flutter at the application level (which isn't required as anyone who works on it will tell you, yada yada yada) but Dart is such a strange choice because it still relies on GC. What's the point? Oh and just to be pedantic, you list ref-counting as a negative of Swift compared to Objective-C. ARC is orthogonal to that. Like I said, ARC came about in iOS 5.0.