On 11 May 2014 08:40, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 5/10/2014 8:54 AM, Manu via Digitalmars-d wrote: >> >> I can't think of many situations where that wouldn't be the case. What >> sort of software is it not an issue to experience intermittent >> freezing? > > > Batch programs, for example a compiler.
Indeed, that was the only one that came to my mind. GC might be better for shell apps because it is unlikely that a collect will ever occur, it'll usually terminate before it gets to it, but there's certainly no hard-dependency on GC in this use case. This is truly a niche usage case though, and yet, it also has no particular incompatibility with any choice of technology, only a slight preference towards GC for the reason that you never bother freeing memory in DMD. If you're prepared to label the largest entertainment industry on the planet a niche, then this sort of work is a hyper-niche... and regardless, not actually incompatible with any particular option. I'd like to consider this form of software for a moment though. Assuming the GC was a library offered beside the language, DDMD for instance would be able to make particularly easy and convenient use of it. Shell apps by comparison _are_ generally small and self-contained. It's far more reasonable to suggest that a shell app can adopt specific and custom allocation patterns when the code is relatively small, function is specific, the life is short, the probability of running into incompatible 3rd party libraries is almost zero by comparison. How many libs does DMD link? This thought has actually left me slightly concerned, that as much as Andrei is accusing me of unreasonably arguing my "staunch niche position that ignores factual realities" (a somewhat offensive and dismissive notion), that there might be some silent, but significant (perhaps even unconscious) element of the same in reverse. > Essentially any program that is not interactive and does not have hard > realtime requirements, which is (possibly) most programs. I'm hard pressed to think of any software I see people using every day which isn't realtime in some sense. The majority of relevant software today is on embedded devices, and visceral touch-based UI is key to their impression of quality. >> Recall too that D has significant opportunity to >> improve on ARC as implemented by other languages, > > > Compiler improvements to improve on ARC are the same technology as used to > improve GC. > > You're essentially arguing that one is easy pickings and the other is > impractically difficult, but they're actually about the same level. Are they? This is the first I've heard such a claim. If that's the case, then that why is there an argument? That work just needs to be done, and we can experiment with both targets... I can fairly easily visualise the path to ARC, but by all prior reports I've heard, awesome GC is practically incompatible with D for various reasons. There were discussions about different advanced options by the experts at dconf last year, which seemed to hit various impasses. And I'm still not even sure if 'awesome GC' will solve my problems? Will it? No matter how awesome it is, it seems conceptually incompatible with my environment. I keep saying, I'm more than happy to be proved wrong (really!), but until someone can, then it's unfair to dismiss my arguments so easily... and I just don't think it's that unreasonable. ARC is an extremely successful technology, particularly in the compiled/native/systems language space (OC, C++/CX, Rust). Is there actually any evidence of significant GC success in this space? Successes all seem to be controlled VM based languages like Java and C#; isolated languages with no intention to interact with existing native worlds. There must be good reason for that apparent separation in trends?