Travis Boucher Wrote:
> 
> The fast, highly optimized web code is a very niche market.

I'm not sure it will remain this way for long.  Look at social networking sites, where people spend a great deal of their time in what are essentially user-created apps.  Make them half as efficient and the "cloud" will need twice the resources to run them.

Sean Kelly wrote:
> Travis Boucher Wrote:
>> The fast, highly optimized web code is a very niche market.
> 
> I'm not sure it will remain this way for long.  Look at social networking sites, where people spend a great deal of their time in what are essentially user-created apps.  Make them half as efficient and the "cloud" will need twice the resources to run them.


I hope it doesn't remain this way.  Personally I am sick of fixing broken PHP code, retarded ruby code, and bad SQL queries.  However, the issue isn't the language as much as it is the coders.

Easy powerful languages = stupid coders who do stupid things.

D is an easy, powerful language, but has one aspect which may protect it against stupid coders.  Its hard to do stupid things in D.  Its harder to create a memory leak in D then it is to prevent one in C.

Hell, I've seen ruby do things which personally I thought was a memory leak at first, to later realize it was just a poor GC implementation. (this is mats ruby, not jruby or rubinius).

I know stupid coders will always exist, but D promotes good practice without sacrificing performance.

== Quote from Travis Boucher (boucher.travis@gmail.com)'s article
> Sean Kelly wrote:
>  Its harder
> to create a memory leak in D then it is to prevent one in C.

void doStuff() {
    uint[] foo = new uint[100_000_000];
}

void main() {
    while(true) {
        doStuff();
    }
}

dsimcha wrote:
> == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
>> Sean Kelly wrote:
>>  Its harder
>> to create a memory leak in D then it is to prevent one in C.
> 
> void doStuff() {
>     uint[] foo = new uint[100_000_000];
> }
> 
> void main() {
>     while(true) {
>         doStuff();
>     }
> }
> 

Hmm, that seems like that should be an implementation bug.  Shouldn't foo be marked for GC once it scope?  (I have never used new on a primitive type, so I don't know)

== Quote from Travis Boucher (boucher.travis@gmail.com)'s article
> dsimcha wrote:
> > == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
> >> Sean Kelly wrote:
> >>  Its harder
> >> to create a memory leak in D then it is to prevent one in C.
> >
> > void doStuff() {
> >     uint[] foo = new uint[100_000_000];
> > }
> >
> > void main() {
> >     while(true) {
> >         doStuff();
> >     }
> > }
> >
> Hmm, that seems like that should be an implementation bug.  Shouldn't foo be marked for GC once it scope?  (I have never used new on a primitive type, so I don't know)

It's conservative GC.  D's GC, along with the Hans Boehm GC and probably most GCs for close to the metal languages, can't perfectly identify what's a pointer and what's not.  Therefore, for sufficiently large allocations there's a high probability that some bit pattern that looks like a pointer but isn't one will keep the allocation alive long after there are no "real" references to it left.

On Fri, 20 Nov 2009 17:28:07 +0300, dsimcha <dsimcha@yahoo.com> wrote:

> == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
>> dsimcha wrote:
>> > == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
>> >> Sean Kelly wrote:
>> >>  Its harder
>> >> to create a memory leak in D then it is to prevent one in C.
>> >
>> > void doStuff() {
>> >     uint[] foo = new uint[100_000_000];
>> > }
>> >
>> > void main() {
>> >     while(true) {
>> >         doStuff();
>> >     }
>> > }
>> >
>> Hmm, that seems like that should be an implementation bug.  Shouldn't
>> foo be marked for GC once it scope?  (I have never used new on a
>> primitive type, so I don't know)
>
> It's conservative GC.  D's GC, along with the Hans Boehm GC and probably most GCs
> for close to the metal languages, can't perfectly identify what's a pointer and
> what's not.  Therefore, for sufficiently large allocations there's a high
> probability that some bit pattern that looks like a pointer but isn't one will
> keep the allocation alive long after there are no "real" references to it left.

Aren't uint array allocations have hasPointers flag set off? I always thought they aren't scanned for pointers (unlike, say, void[]).

== Quote from Denis Koroskin (2korden@gmail.com)'s article
> On Fri, 20 Nov 2009 17:28:07 +0300, dsimcha <dsimcha@yahoo.com> wrote:
> > == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
> >> dsimcha wrote:
> >> > == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
> >> >> Sean Kelly wrote:
> >> >>  Its harder
> >> >> to create a memory leak in D then it is to prevent one in C.
> >> >
> >> > void doStuff() {
> >> >     uint[] foo = new uint[100_000_000];
> >> > }
> >> >
> >> > void main() {
> >> >     while(true) {
> >> >         doStuff();
> >> >     }
> >> > }
> >> >
> >> Hmm, that seems like that should be an implementation bug.  Shouldn't foo be marked for GC once it scope?  (I have never used new on a primitive type, so I don't know)
> >
> > It's conservative GC.  D's GC, along with the Hans Boehm GC and probably
> > most GCs
> > for close to the metal languages, can't perfectly identify what's a
> > pointer and
> > what's not.  Therefore, for sufficiently large allocations there's a high
> > probability that some bit pattern that looks like a pointer but isn't
> > one will
> > keep the allocation alive long after there are no "real" references to
> > it left.
> Aren't uint array allocations have hasPointers flag set off? I always thought they aren't scanned for pointers (unlike, say, void[]).

Right, but they can still be the target of false pointers.  In this case, false pointers keep each instance of foo[] alive, leading to severe memory leaks.

dsimcha wrote:
> == Quote from Denis Koroskin (2korden@gmail.com)'s article
>> On Fri, 20 Nov 2009 17:28:07 +0300, dsimcha <dsimcha@yahoo.com> wrote:
>>> == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
>>>> dsimcha wrote:
>>>>> == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
>>>>>> Sean Kelly wrote:
>>>>>>  Its harder
>>>>>> to create a memory leak in D then it is to prevent one in C.
>>>>> void doStuff() {
>>>>>     uint[] foo = new uint[100_000_000];
>>>>> }
>>>>>
>>>>> void main() {
>>>>>     while(true) {
>>>>>         doStuff();
>>>>>     }
>>>>> }
>>>>>
>>>> Hmm, that seems like that should be an implementation bug.  Shouldn't
>>>> foo be marked for GC once it scope?  (I have never used new on a
>>>> primitive type, so I don't know)
>>> It's conservative GC.  D's GC, along with the Hans Boehm GC and probably
>>> most GCs
>>> for close to the metal languages, can't perfectly identify what's a
>>> pointer and
>>> what's not.  Therefore, for sufficiently large allocations there's a high
>>> probability that some bit pattern that looks like a pointer but isn't
>>> one will
>>> keep the allocation alive long after there are no "real" references to
>>> it left.
>> Aren't uint array allocations have hasPointers flag set off? I always
>> thought they aren't scanned for pointers (unlike, say, void[]).
> 
> Right, but they can still be the target of false pointers.  In this case, false
> pointers keep each instance of foo[] alive, leading to severe memory leaks.

But the issue is more of a GC implementation issue then a language issue, correct?  Or is this an issue of all lower level language garbage collectors?

I do not know much about GC, just basic concepts.

== Quote from Travis Boucher (boucher.travis@gmail.com)'s article
> dsimcha wrote:
> > == Quote from Denis Koroskin (2korden@gmail.com)'s article
> >> On Fri, 20 Nov 2009 17:28:07 +0300, dsimcha <dsimcha@yahoo.com> wrote:
> >>> == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
> >>>> dsimcha wrote:
> >>>>> == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
> >>>>>> Sean Kelly wrote:
> >>>>>>  Its harder
> >>>>>> to create a memory leak in D then it is to prevent one in C.
> >>>>> void doStuff() {
> >>>>>     uint[] foo = new uint[100_000_000];
> >>>>> }
> >>>>>
> >>>>> void main() {
> >>>>>     while(true) {
> >>>>>         doStuff();
> >>>>>     }
> >>>>> }
> >>>>>
> >>>> Hmm, that seems like that should be an implementation bug.  Shouldn't foo be marked for GC once it scope?  (I have never used new on a primitive type, so I don't know)
> >>> It's conservative GC.  D's GC, along with the Hans Boehm GC and probably
> >>> most GCs
> >>> for close to the metal languages, can't perfectly identify what's a
> >>> pointer and
> >>> what's not.  Therefore, for sufficiently large allocations there's a high
> >>> probability that some bit pattern that looks like a pointer but isn't
> >>> one will
> >>> keep the allocation alive long after there are no "real" references to
> >>> it left.
> >> Aren't uint array allocations have hasPointers flag set off? I always thought they aren't scanned for pointers (unlike, say, void[]).
> >
> > Right, but they can still be the target of false pointers.  In this case, false pointers keep each instance of foo[] alive, leading to severe memory leaks.
> But the issue is more of a GC implementation issue then a language issue, correct?

Yes.

> Or is this an issue of all lower level language garbage collectors?

Kinda sorta.  It's possible, but not easy, to implement fully precise GC (except for the extreme corner case of unions of reference and non-reference types) in a close to the metal, statically compiled language.

On Fri, 20 Nov 2009 19:24:05 +0300, dsimcha <dsimcha@yahoo.com> wrote:

> == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
>> dsimcha wrote:
>> > == Quote from Denis Koroskin (2korden@gmail.com)'s article
>> >> On Fri, 20 Nov 2009 17:28:07 +0300, dsimcha <dsimcha@yahoo.com>  
>> wrote:
>> >>> == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
>> >>>> dsimcha wrote:
>> >>>>> == Quote from Travis Boucher (boucher.travis@gmail.com)'s article
>> >>>>>> Sean Kelly wrote:
>> >>>>>>  Its harder
>> >>>>>> to create a memory leak in D then it is to prevent one in C.
>> >>>>> void doStuff() {
>> >>>>>     uint[] foo = new uint[100_000_000];
>> >>>>> }
>> >>>>>
>> >>>>> void main() {
>> >>>>>     while(true) {
>> >>>>>         doStuff();
>> >>>>>     }
>> >>>>> }
>> >>>>>
>> >>>> Hmm, that seems like that should be an implementation bug.   
>> Shouldn't
>> >>>> foo be marked for GC once it scope?  (I have never used new on a
>> >>>> primitive type, so I don't know)
>> >>> It's conservative GC.  D's GC, along with the Hans Boehm GC and  
>> probably
>> >>> most GCs
>> >>> for close to the metal languages, can't perfectly identify what's a
>> >>> pointer and
>> >>> what's not.  Therefore, for sufficiently large allocations there's  
>> a high
>> >>> probability that some bit pattern that looks like a pointer but  
>> isn't
>> >>> one will
>> >>> keep the allocation alive long after there are no "real" references  
>> to
>> >>> it left.
>> >> Aren't uint array allocations have hasPointers flag set off? I always
>> >> thought they aren't scanned for pointers (unlike, say, void[]).
>> >
>> > Right, but they can still be the target of false pointers.  In this  
>> case, false
>> > pointers keep each instance of foo[] alive, leading to severe memory  
>> leaks.
>> But the issue is more of a GC implementation issue then a language
>> issue, correct?
>
> Yes.
>
>> Or is this an issue of all lower level language garbage
>> collectors?
>
> Kinda sorta.  It's possible, but not easy, to implement fully precise GC (except
> for the extreme corner case of unions of reference and non-reference types) in a
> close to the metal, statically compiled language.

Unions could be deprecated in favor of tagged unions (see an example in Cyclone http://cyclone.thelanguage.org/wiki/Tagged%20Unions). Would that help?