4 ms·
IMO the choice of reference counting for memory management means Swift is going to lose out to garbage collected languages for most problem domains. It makes se
by cageface 8y ago
IMO the choice of reference counting for memory management means Swift is going to lose out to garbage collected languages for most problem domains. It makes sense for UIKit but not for most backend work.
- skohan 8y agoWhat would you say is the problem with Reference Counting for back-end work? Maybe it's because I come from a C/C++ background, but declaring a few weak references here and there never felt like much of a hindrance to me.
- MaxBarraclough 8y agoOn the flipside though: * You're always thinking of whether you might need to use weak refs, right? That's a cognitive load that you would otherwise be spared. * What are the consequences when you get it wrong? * How probable is a mistake, particularly when working with a large complex codebase that you didn't create, and don't fully understand? * How probable is it that you might fail to detect a mistake, for a long time?
- vlozko 8y agoCould you, at least, provide something to substantiate your opinion? There's ups and downs to both approaches. But you should note that reference counting, for the most part, is handled for you at compile time.
- cageface 8y agoMy iOS code is loaded with manual weak ref handling. It’s easy to get wrong. It’s an extra cognitive load and source of bugs. I’d say on pretty much every iOS project I’ve been on there’s been at least one client visible bug caused by forgetting to use a weak ref somewhere.