What matters most will be the quality of implementation. Is the compiler smart enough to know that an object passed 3 routines deep doesn't really escape the st

What matters most will be the quality of implementation. Is the compiler smart enough to know that an object passed 3 routines deep doesn't really escape the stack scope? If it can do that, it can elide all the cost of either approach. This is the plan with Swift and what makes it zippy. bone of contention with sweeping collectors is constantly walking The real problem is that you cannot determine when the program will pause. It makes interactive and soft realtime impossible with gc. (Hard realtime should not run a generic allocator at all.) You can't write anything but servers and unpleasantly unresponsive apps. Android developers have to carefully jump through hoops to avoid allocating any RAM at all if they don't want to bug their users. For years when the chips were slow, ref counting was a major competitive advantage for iPhone. A hundred-billion dollar win. And then there's system software. You can't afford a live, unpredictable runtime messing with you in systems code so anything that touches low level code can't use gc. There's a disincentive to really invest in a language that simply can't ever do a full stack, even if you're unlikely to need to write a device driver anytime soon. That's why no major browsers, performant ACID databases, or fast app servers depend on RAM gc.