<div dir="ltr">On 9 October 2013 15:23, PauloPinto <span dir="ltr"><<a href="mailto:pjmlp@progtools.org" target="_blank">pjmlp@progtools.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wednesday, 9 October 2013 at 05:15:53 UTC, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 9 October 2013 08:58, ponce <<a href="mailto:contact@gmsfrommars.fr" target="_blank">contact@gmsfrommars.fr</a>> wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Tuesday, 8 October 2013 at 22:45:51 UTC, Adam D. Ruppe wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Eh, not necessarily. If it expands to static assert(!__traits(**<u></u>hasAnnotationRecursive,<div class="im"><br>
uses_gc));, then the only ones that *need* to be marked are the lowest<br>
level ones. Then it figures out the rest only on demand.<br>
<br>
Then, on the function you care about as a user, you say nogc and it tells<br>
you if you called anything and the static assert stacktrace tells you where<br>
it happened.<br>
<br>
Of course, to be convenient to use, phobos would need to offer<br>
non-allocating functions, which is indeed a fair amount of work, but they<br>
wouldn't *necessarily* have to have the specific attribute.<br>
<br>
</div></blockquote><div class="im">
<br>
But is it even necessary? There isn't a great deal of evidence that<br>
someone interested in optimization will be blocked on this particular<br>
problem, like Peter Alexander said.<br>
<br>
GC hassle is quite common but not that big a deal:<br>
- Manu: "Consequently, I avoid the GC in D too, and never had any major<br></div>
problems, only inconvenience." <a href="http://www.reddit.com/r/**" target="_blank">http://www.reddit.com/r/**</a><br>
programming/comments/1nxs2i/**<u></u>the_state_of_rust_08/ccnefe7<<a href="http://www.reddit.com/r/programming/comments/1nxs2i/the_state_of_rust_08/ccnefe7" target="_blank">h<u></u>ttp://www.reddit.com/r/<u></u>programming/comments/1nxs2i/<u></u>the_state_of_rust_08/ccnefe7</a>><div class="im">
<br>
- Dav1d: said he never had a GC problem with BRala (minecraft client)<br>
- Me: I had a small ~100ms GC pause in one of my games every 20 minutes,<br>
more often than not I don't notice it<br>
<br>
So a definitive written rebutal we can link to would perhaps be helpful.<br>
<br>
</div></blockquote>
<br><div><div class="h5">
I might just add, that while my experience has been that I haven't had any<br>
significant technical problems when actively avoiding the GC, the<br>
inconvenience is considerably more severe than I made out in that post (I<br>
don't want to foster public negativity).<br>
But it is actually really, really inconvenient. If that's my future with D,<br>
then I'll pass, just as any un-biased 3rd party would.<br>
<br>
I've been simmering on this issue ever since I took an interest in D. At<br>
first I was apprehensive to accept the GC, then cautiously optimistic that<br>
the GC might be okay. But I have seen exactly no movement in this area as<br>
long as I've been following D, and I have since reverted to a position in<br>
absolute agreement with the C++ users. I will never accept the GC in it's<br>
current form for all of my occupational requirements; it's implicitly<br>
non-deterministic, and offers very little control over performance<br>
characteristics.<br>
I've said before that until I can time-slice the GC, and it does not stop<br>
the world, then it doesn't satisfy my requirements. I see absolutely no<br>
motion towards that goal.<br>
If I were one of those many C++ users evaluating D for long-term adoption<br>
(and I am!), I'm not going to invest the future of my career and industry<br>
in a complete question mark which given years of watching already, is<br>
clearly going nowhere.<br>
As far as the GC is concerned, with respect to realtime embedded software,<br>
I'm out. I've completely lost faith. And it's going to take an awful lot<br>
more to restore my faith again than before.<br>
<br>
What I want is an option to replace the GC with ARC, just like Apple did.<br>
Clearly they came to the same conclusion, probably for exactly the same<br>
reasons.<br>
Apple have a policy of silky smooth responsiveness throughout the OS and<br>
the entire user experience. They consider this a sign of quality and<br>
professionalism.<br>
As far as I can tell, they concluded that non-deterministic GC pauses were<br>
incompatible with their goal. I agree.<br>
I think their experience should be taken very seriously. They have a<br>
successful platform on weak embedded hardware, with about a million<br>
applications deployed.<br>
<br>
I've had a lot of conversations with a lot of experts, plenty of<br>
conversations at dconf, and nobody could even offer me a vision for a GC<br>
that is acceptable.<br>
As far as I can tell, nobody I talked to really thinks a GC that doesn't<br>
stop the world, which can be carefully scheduled/time-sliced (ie, an<br>
incremental, thread-local GC, or whatever), is even possible.<br>
<br>
I'll take ARC instead. It's predictable, easy for all programmers who<br>
aren't experts on resource management to understand, and I have DIRECT<br>
control over it's behaviour and timing.<br>
<br>
But that's not enough, offering convenience while trying to avoid using the<br>
GC altogether is also very important. You should be able to write software<br>
that doesn't allocate memory. It's quite hard to do in D today. There's<br>
plenty of opportunity for improvement.<br>
<br>
I'm still keenly awaiting a more-developed presentation of Andrei's<br>
allocators system.<br>
</div></div></blockquote>
<br>
<br>
<br>
Apple dropped the GC and went ARC instead, because they never managed to make it work properly.<br>
<br>
It was full of corner cases, and the application could crash if those cases were not fully taken care of.<br>
<br>
Or course the PR message is "We dropped GC because ARC is better" and not "We dropped GC because we failed".<br>
<br>
Now having said this, of course D needs a better GC as the current one doesn't fulfill the needs of potential users of the language.<br></blockquote><div><br></div><div>Well, I never read that article apparently... but that's possibly even more of a concern if true.</div>
<div>Does anyone here REALLY believe that a bunch of volunteer contributors can possibly do what apple failed to do with their squillions of dollars and engineers?</div><div>I haven't heard anybody around here propose the path to an acceptable solution. It's perpetually in the too-hard basket, hence we still have the same GC as forever and it's going nowhere.</div>
</div></div></div>