On 9 October 2013 15:23, PauloPinto <pj...@progtools.org> wrote: > On Wednesday, 9 October 2013 at 05:15:53 UTC, Manu wrote: > >> On 9 October 2013 08:58, ponce <cont...@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<h** >>> ttp://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. >> > > > > Apple dropped the GC and went ARC instead, because they never managed to > make it work properly. > > It was full of corner cases, and the application could crash if those > cases were not fully taken care of. > > Or course the PR message is "We dropped GC because ARC is better" and not > "We dropped GC because we failed". > > 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. >
Well, I never read that article apparently... but that's possibly even more of a concern if true. 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? 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.