Deterministic Memory Management With Standard Library Progress

[Inquie via Digitalmars-d]

> Finally GC problems are completely exagerated. It only runs 
> when used so having it to manage exceptions only for example is 
> completely viable, and it is possible to dereference threads if 
> you don't want them to be seen by the GC. Using GC globally and 
> avoiding it locally on heat points has proved to be a 
> successful strategy within the community. So I wouldn't worry 
> too much, giving it a try is paramount.

Please stop making this argument. Just because one can amortize 
out the effect of the GC does not in any way change the fact that 
it is a stop the world GC and for certain applications this is 
provably a show stopper. One can come up with any number of 
commercial apps that fail using D's GC. Some applications require 
near real time behavior and D's GC does not provide any bounds on 
how long it runs... regardless of any average behavior(as that is 
meaningless when it only takes once to kill a person, create an 
audio glitch, etc). All these apps work fine with deterministic 
memory management or possibly other methods, but not D's GC.

It is not a viable solution just because it is a solution for 
you. When you start writing these apps that simply do not 
function to the standards set by the customer and this is all due 
to D's GC, then you will experience why it is bad. Until then, 
you won't have a clue.

It doesn't matter if it works 99.99% of the time, with these 
applications that may run for months at a time and have critical 
behavior constraints, 99.99% doesn't look that great. So, please 
don't push your ideals, motivations, experiences on others and 
just be honest with them. D's GC sucks for near real time 
applications, and it has problems. It one avoids the GC as best 
as they can using traditional techniques, it minimizes the effect 
of the GC and makes the app closer to real time.