The "no gc" crowd

[Nick Sabalausky]

On Tue, 08 Oct 2013 19:22:34 -0700
Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
> 
> It's clear that the perception of GC will not change soon, however
> good or not the arguments may be as applied to various situations and 
> projects. It is also a reality that our GC is slow.
> 
> So we need to attack this problem from multiple angles:
> 
> * Make RefCounted work as immutable data. There will be a casting
> away of immutability in there, but since it's under the aegis of the
> standard library, it is admissible. All implementations must ensure
> RefCounted works.
> 
> * Add reference counted slice and associative array types that are as 
> close as humanly possible to the built-in ones.
> 
> * Advertise all of the above in a top module such as std.refcounted. 
> It's amazing how many D programmers have no idea RefCounted even
> exists.
> 
> * Review all of Phobos for hidden allocations and make appropriate 
> decisions on how to give the user more control over allocation. I
> have some idea on how that can be done, at various disruption costs.
> 
> * Get Robert Schadek's precise GC in. Walter and I have become 101% 
> convinced a precise GC is the one way to go about GC.
> 
> I'm up to my neck in D work for Facebook so my time is well spent. We 
> must definitely up the ante in terms of development speed, and pronto.
> 

Unless the eventual allocator stuff would make special refcounted
slices/AAs redundant (which actually wouldn't be too terrible, really),
then I think all that sounds great. Add in a simple way to do full
closures without GC allocation and it'd be a big win.

However, even with all that, I still feel it would be in D's best
interest to have a trivial[1] way to guarantee no GC allocations *at
least* on a whole-program level, if not also on a finer-grained basis.

*Even if* it's successfully argued that "no GC" is rarely, if ever,
a valid requirement (which I find questionable anyway), it's *still*
an important feature for D *just because* there's so much demand for
it. When your goal is to successfully market something, there *is*
value in fulfilling a common need, even if it's just a perceived need.
(But again, I'm not claiming "no GC" to be an imaginary need. Just
saying that it really doesn't matter if it's imagined or real. The
mere demand for it makes it a legitimate concern.)

[1] "Trival" == Doesn't require the user to modify or replace anything
in druntime or phobos, and all violations are automatically caught at
compiletime.