The purpose of D (GC rant, long)

[Kyle Furlong]

Serg Kovrov wrote:
> Hello, fellows!
> 
> First of all a small disclaimer - I really do like D, I appreciate
> Walter's great work, and I actually do use it (or at least trying to) in
> my personal projects. So it's not just complains for the sake of
> complaining.
> 
> In D I like (or at least can live with) pretty much everything but one
> thing. The memory management thing. I complain to this before, and yet
> again I loose my nerves. Call me memory freak if you will. That the
> reason I do not like Java and .NET. That the reason I was stick with C++
> instead of jumping to managed platforms long time ago.
> 
> The problem for me is not that GC is hard-coupled with *standard*
> library. Actually I do like the idea to have GC in *standard* library.
> The real pain for me is that (as I see it) D is designed to be used with 
> GC. That is, operations with arrays and strings heavy relaying on GC. 
> When I say "D", I mean "D and Phobos". For me they are one thing.
> 
> The problem is, I can't do without standard library (that is Phobos).
> That's because I'm simple folk. I really am. I can't write my own or
> even use third-party. Sorry Sean, with all my respect, I cant invest my
> time to Ares. My experience taught me just that - to stick
> with standard library.
> 
> As bottom line, there are a few statements about me:
> - I am *not* a system developer. I am an application developer.
> - I'm very paranoid regarding resources (memory in particular).
> - I *do* like GC, but will use it only if I can fully control it (as 
> user, of course).
> - I can live with manual memory management, but I *will not* write basic
> routines to substitute standard library.
> 
> 
> And now point of my rant: For whom D is really designed?
> 
> If you are an application developer who do not care much about memory 
> usage - "go managed" (that is Java, .Net).
> 
> System developer? Have no idea. Maybe. But I'm sure they have to roll 
> their own pretty much everything (to get rid of GC). And how much there 
> are system development comparing to application development?
> 
> Embedded devices? Again, with GC, no way. And I leave out compiler 
> support for that matter.
> 
> 
> What I really would like to know is, will standard library ever have 
> full functionality without using GC? Will GC evolving further? Which way?
> 
> No offense, those nifty language features that you people constantly 
> discussing here, are great indeed, but what most simple fellows like me 
> needed is pragmatic stuff like controllable GC and/or ability to 
> painless ignore GC.
> 

If you are writing your own memory management anyways, whats to stop you 
from implementing your own GC, which will be as paranoid about memory as 
you are? The hooks are all there in the phobos source. Ares makes it 
even simpler, I believe, but I think Sean can help you with that better 
than I can.

That said, isnt one able to disable the GC through std.gc.disable() or 
some such call? What exactly does it do, now that I think about it? 
Perhaps, for cases such as this, it would be helpful for there to be a 
page on digitalmars.com/d/ which lists the language features that are gc 
supported such that any prospective developers of the OP's bent can 
easily avoid the allocations and memory waste they dont want to invoke.