On Mon, 03 Feb 2014 19:49:04 -0500, Adam Wilson <[email protected]> wrote:
On Mon, 03 Feb 2014 16:24:52 -0800, NoUseForAName <[email protected]> wrote:
On Monday, 3 February 2014 at 23:00:23 UTC, woh wrote:
ur right I never thought of that, I bet all them game devs never
thought of it either, they so dumb. I bet they never tried to use a
GC, what fools! Endless graphs of traced objects, oh yes oh yes! It
only runs when I allocate, oh what a fool I've been, please castigate
me harder!
Also people should consider that Apple (unlike C++ game devs) did not
have a tradition of contempt for GC. In fact they tried GC *before*
they switched to ARC. The pro-GC camp always likes to pretend that the
anti-GC one is just ignorant, rejecting GC based on prejudice not
experience but Apple rejected GC based on experience.
GCed Objective-C did not allow them to deliver the user experience they
wanted (on mobile), because of the related latency issues. So they
switched to automated ref counting. It is not in question that ref
counting sacrifices throughput (compared to an advanced GC) but for
interactive, user facing applications latency is much more important.
That may be the case, but StackOverflow shows that ARC hasn't been
panacea in Apple land either. Way to many people don't understand ARC
and how to use it, and subsequently beg for help understanding
heisenleaks and weak references. ARC places a higher cognitive load on
the programmer than a GC does. And Android runs just fine with GC'ed
apps, but ARC guys don't want to talk about Google's successes there.
Where you have to be cognizant is avoiding cycles. Plain and simple. And
it's not that difficult. The compiler takes care of the rest. It's
somewhat magical I suppose :) Managing your autorelease pools can make a
difference, but is not necessarily critical.
I think when working on embedded systems, it is quite important to
understand the limitations and strengths of the language/hardware you are
using, much more so than on a full PC/Server. Where ARC really beats the
GC is on memory usage. It's very very close to malloc/free usage.
I would love to see D attain an ARC system, especially if it can link
seamlessly with Objective-C. What I don't know is if one can replace a GC
with an ARC memory manager without having to port any high-level code. I
don't think that is the case. Which leads me to think -- is it even
possible to write druntime/phobos in an agnostic way? If it isn't, what
subset can be done that way?
-Steve
