The purpose of D (GC rant, long)

Serg Kovrov kovrov at no.spam
Thu Oct 26 02:31:07 PDT 2006


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.

-- 
serg.



More information about the Digitalmars-d mailing list