The purpose of D (GC rant, long)

[Sean Kelly]

Serg Kovrov wrote:
> 
> 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.

No problem.  I'd say this is true of most programmers.

> And now point of my rant: For whom D is really designed?

I think D is designed for a larger audience than C++, since it's 
somewhat forgiving in design (similar to Java), but can be used for 
systems programming (similar to C++).  By comparison, C++ was truly 
designed for advanced programmers despite the range of people that 
actually use it.

> If you are an application developer who do not care much about memory 
> usage - "go managed" (that is Java, .Net).

...and D.

> 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?

There are very few systems developers compared to application 
developers.  But D can be used here as well.  The standard library might 
be largely ignored and dynamic arrays might be used carefully, but D can 
really do everything C++ can here, unless you absolutely insist on 
having user-defined data types that are indistinguishable from built-in 
types.

> Embedded devices? Again, with GC, no way. And I leave out compiler 
> support for that matter.

And embedded developers can turn the GC off or write a custom GC to 
operate within their constraints.  However, I disagree that GC is 
completely incompatible with embedded devices.  Java runs on just about 
everything these days and unlike D it doesn't even offer the option of 
stack allocation or explicit deletion.

> What I really would like to know is, will standard library ever have 
> full functionality without using GC? Will GC evolving further? Which way?

I'd like to think that the standard library will eventually minimize its 
use of GC allocations over time, but they will never be completely 
eliminated.  Some algorithms just aren't represented well without some 
form of internal dynamic allocation.

> 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.

A controllable GC isn't terribly difficult.  In fact, std.gc in Phobos 
offers a lot of functionality right now.


Sean