The "no gc" crowd

[Manu]

On 9 October 2013 08:58, ponce <contact at gmsfrommars.fr> wrote:

> On Tuesday, 8 October 2013 at 22:45:51 UTC, Adam D. Ruppe wrote:
>
>>
>> Eh, not necessarily. If it expands to static assert(!__traits(**hasAnnotationRecursive,
>> uses_gc));, then the only ones that *need* to be marked are the lowest
>> level ones. Then it figures out the rest only on demand.
>>
>> Then, on the function you care about as a user, you say nogc and it tells
>> you if you called anything and the static assert stacktrace tells you where
>> it happened.
>>
>> Of course, to be convenient to use, phobos would need to offer
>> non-allocating functions, which is indeed a fair amount of work, but they
>> wouldn't *necessarily* have to have the specific attribute.
>>
>
> But is it even necessary? There isn't a great deal of evidence that
> someone interested in optimization will be blocked on this particular
> problem, like Peter Alexander said.
>
> GC hassle is quite common but not that big a deal:
> - Manu: "Consequently, I avoid the GC in D too, and never had any major
> problems, only inconvenience." http://www.reddit.com/r/**
> programming/comments/1nxs2i/**the_state_of_rust_08/ccnefe7<http://www.reddit.com/r/programming/comments/1nxs2i/the_state_of_rust_08/ccnefe7>
> - Dav1d: said he never had a GC problem with BRala (minecraft client)
> - Me: I had a small ~100ms GC pause in one of my games every 20 minutes,
> more often than not I don't notice it
>
> So a definitive written rebutal we can link to would perhaps be helpful.
>

I might just add, that while my experience has been that I haven't had any
significant technical problems when actively avoiding the GC, the
inconvenience is considerably more severe than I made out in that post (I
don't want to foster public negativity).
But it is actually really, really inconvenient. If that's my future with D,
then I'll pass, just as any un-biased 3rd party would.

I've been simmering on this issue ever since I took an interest in D. At
first I was apprehensive to accept the GC, then cautiously optimistic that
the GC might be okay. But I have seen exactly no movement in this area as
long as I've been following D, and I have since reverted to a position in
absolute agreement with the C++ users. I will never accept the GC in it's
current form for all of my occupational requirements; it's implicitly
non-deterministic, and offers very little control over performance
characteristics.
I've said before that until I can time-slice the GC, and it does not stop
the world, then it doesn't satisfy my requirements. I see absolutely no
motion towards that goal.
If I were one of those many C++ users evaluating D for long-term adoption
(and I am!), I'm not going to invest the future of my career and industry
in a complete question mark which given years of watching already, is
clearly going nowhere.
As far as the GC is concerned, with respect to realtime embedded software,
I'm out. I've completely lost faith. And it's going to take an awful lot
more to restore my faith again than before.

What I want is an option to replace the GC with ARC, just like Apple did.
Clearly they came to the same conclusion, probably for exactly the same
reasons.
Apple have a policy of silky smooth responsiveness throughout the OS and
the entire user experience. They consider this a sign of quality and
professionalism.
As far as I can tell, they concluded that non-deterministic GC pauses were
incompatible with their goal. I agree.
I think their experience should be taken very seriously. They have a
successful platform on weak embedded hardware, with about a million
applications deployed.

I've had a lot of conversations with a lot of experts, plenty of
conversations at dconf, and nobody could even offer me a vision for a GC
that is acceptable.
As far as I can tell, nobody I talked to really thinks a GC that doesn't
stop the world, which can be carefully scheduled/time-sliced (ie, an
incremental, thread-local GC, or whatever), is even possible.

I'll take ARC instead. It's predictable, easy for all programmers who
aren't experts on resource management to understand, and I have DIRECT
control over it's behaviour and timing.

But that's not enough, offering convenience while trying to avoid using the
GC altogether is also very important. You should be able to write software
that doesn't allocate memory. It's quite hard to do in D today. There's
plenty of opportunity for improvement.

I'm still keenly awaiting a more-developed presentation of Andrei's
allocators system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131009/100123d5/attachment.html>