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.

Serg Kovrov wrote:

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

I think that is one of the features of D. I miss my GC when doing C/C++.

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

Sounds like C++ would be a better match, GC will be optional in C++0X ?


I think that garbage collection is a nice language FEATURE, and the only
part I don't like is when it doesn't work and the other remaining bugs.
But it *is* something of a must, once it's in the language and library -
I don't think you can use D without using GC in (parts) of your program.

See http://www.digitalmars.com/d/garbage.html for the rationale why.

I've used GC in both C (Apache "pooling" functions) and C++ (as a lib),
and it's useful there too ? I don't think you *have* to go to Java/C#.
Most of the time I don't miss managing memory resources manually more
than I miss writing assembler code, and computer is better at it too.

At least for me, D fills a niche between C and Java ? A simpler C++...

--anders

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.

Hi Kyle Furlong, you wrote:
> 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.

Sorry if I wasn't clear, perhaps it's because of my English. I do not intend to write low level stuff like GC. I write applications.

-- 
serg.

Kyle Furlong wrote:
> 
> 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? 

When memory is allocated from the GC it first looks to see if it has any available internally.  If it can't find any it runs a collection and looks again.  If it still can't find any then it obtains more memory from the OS and uses a portion of that for the allocation.  Setting gc.disable() prevents the collection run from occurring so the GC will simply obtain more memory from the OS when it runs out.  The reason behind this is that collections can take a long time, and performance-critical sections of code don't necessarily want to wait for a collection to occur just because they called 'new'.  So they'll either disable and re-enable the GC around critical sections of code or they'll simply keep the GC disabled and manually collect during idle periods using gc.fullCollect().

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

Now that memory is not freed when string.length is set to zero it's quite possible to avoid most reallocations simply by preallocating in buffers before using them (ie. set length to some large number and then back to zero).  However, some operations will still cause an allocation, such as appending to a slice.


Sean

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

I can understand your desire to control memory explicitly. I grew up programming C and C++, and considered myself a professional, and professionals have complete control over the operation of their programs. gc was for lazy, wussy, less competent programmers. I bought the conventional wisdom that gc was slow and inefficient.

Then, for a project my employer put me on, I had to use a gc, in fact, I had to work on a gc. I slowly came to realize I was wrong about gc on all counts.

Then I began to think about why C++ was so complicated. I eventually began to realize it's because of explicit memory management. Have a gc, and suddenly you can make a language with even greater power that is much, much simpler.

For one example, you cannot do array slices in C++ without considerable agony. In D, they are easy as pie.

P.S. It *is* true (before D) that gc based languages are slower than C/C++. The conventional wisdom says that this is caused by the gc. This simply is not true, the slowness is usually caused by lack of expressiveness in the language (Java) or dynamic typing (Python, Javascript, etc.).

Walter Bright wrote:
> 
> Then I began to think about why C++ was so complicated. I eventually began to realize it's because of explicit memory management. Have a gc, and suddenly you can make a language with even greater power that is much, much simpler.

After using D for a bit, I came to the same conclusion.  That isn't to say you can completely forget about the cost of reallocations or data ownership, but having a GC simplifies the things that should be simple, without creating additional complexity elsewhere.

> For one example, you cannot do array slices in C++ without considerable agony. In D, they are easy as pie.

True enough.  I have a slice class I use in C++ for specialized purposes (a compiler, for example), but dealing with the memory ownership issues are just too much of a headache for apps where data doesn't have such a predictable lifetime.

> P.S. It *is* true (before D) that gc based languages are slower than C/C++. The conventional wisdom says that this is caused by the gc. This simply is not true, the slowness is usually caused by lack of expressiveness in the language (Java) or dynamic typing (Python, Javascript, etc.).

I think another issue is that garbage collection *can* cause a noticeable stutter in user applications which pay no attention to memory management, and it's easy for someone to point at that hitch and proclaim that garbage collection itself is slow.  People seem to like the straw man argument for some reason.


Sean

Serg Kovrov wrote:
> Hi Kyle Furlong, you wrote:
>> 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.
> 
> Sorry if I wasn't clear, perhaps it's because of my English. I do not intend to write low level stuff like GC. I write applications.
> 

... and in those applications you said you were willing to write manual memory management code. I don't think the step from there to hooking your malloc/free code with the gc hooks is that difficult. I mean, in any sane manually managed memory environment, you are gonna want to have some sort of bookkeeping anyways, so why not implement it in a way that would benefit you? But perhaps I really did misunderstand you.

How much does the runtime, generated code and Phobos depend on the GC?
Does it try to optimize out allocations or delete things it can?
For example, does this preform one allocation or several?

char[] foo = "abc", bar = "baz";
char[] ret = foo ~ bar ~ foo;

// ret.length = 9;
// ret[0..3] = foo;
// ret[3..6] = bar;
// ret[6..9] = foo;

and would these temporaries get deleted (or maybe not even created)?

if((foo ~ bar)[4]=='g') go();

//auto __tmp = foo ~ bar
//if(__tmp[4] == 'g') go();
//delete __tmp;

or

//if( (foo.length>4 && foo[4]=='g') || bar[4-foo.length]=='g') go();