On Thursday, 11 September 2014 at 13:16:07 UTC, Marc Schütz wrote:
> On Thursday, 11 September 2014 at 12:38:54 UTC, Andrey Lifanov wrote:
>> Hello everyone! Being a C/C++ programmer I don't understand, why such language as D (system programming language) implemented garbage collector as a core feature, not as additional optional module or library.
>
> I can enlighten you ;-) The reason is safety. Past experience (especially with C & C++) has shown that manual memory management is easy to get wrong. Besides, certain features would not easily be possible without it (dynamic arrays, closures).

GC is hugely important for concurrent programming as well.  Many of the more powerful techniques are basically impossible without garbage collection.

But I think this largely comes down to standard library design.  Java, for example, is a pretty okay language from a syntax perspective.  The problem with it is more that doing anything with the standard library requires generating tons of often temporary objects.  In the server programming realm, an unbelievable amount of effort has been put into working around this particular problem (look at what the Netty group has been doing, for example).  So it's not so much that the language supports garbage collection as that the established programming paradigm encourages you to lean heavily on it.

By allowing manual memory management, D is far closer to C++.  The problem is that, like Java, many APIs in the standard library are written in such a way that memory allocations are unavoidable.  However, it doesn't have to be this way.  An essential design rule for Tango, for example, was to perform no hidden allocations anywhere.  And it's completely possible with Tango to write an application that doesn't allocate at all once things are up and running.  With Phobos... not so much.

In short, I think that a crucial factor affecting the perception of a language is its standard library.  It stands as a template for how code in that language is intended to be written, and is the framework from which essentially all applications are built.  Breaking from this tends to be difficult to the point of where you're really better off looking for a different language that suits your needs better.

I think Java is in a weird spot in that it's so deeply entrenched at this point that many think it's easier to try and force people to change their programming habits than it is to get them to use a different language.  Though encouraging a transition to a compatible language with better fundamentals is probably preferable (Scala?).

C++ is kind of in the same situation, which I guess is why some feel that C++ interop might be a good thing.  But realistically, working with a truly hybrid code base only serves to further complicate things when the motivating goal is simplification.  It's typically far preferable to simply have communicating agents written in different languages that all talk the same protocol.  That C++ app can go into maintenance mode and the Java, D, and whatever other new stuff just talks to it via a socket connection and then shivers and washes its hands when done.

Am 11.09.2014 18:02, schrieb Sean Kelly:
> On Thursday, 11 September 2014 at 13:16:07 UTC, Marc Schütz wrote:
>> On Thursday, 11 September 2014 at 12:38:54 UTC, Andrey Lifanov wrote:
>>> Hello everyone! Being a C/C++ programmer I don't understand, why such
>>> language as D (system programming language) implemented garbage
>>> collector as a core feature, not as additional optional module or
>>> library.
>>
>> I can enlighten you ;-) The reason is safety. Past experience
>> (especially with C & C++) has shown that manual memory management is
>> easy to get wrong. Besides, certain features would not easily be
>> possible without it (dynamic arrays, closures).
>
> GC is hugely important for concurrent programming as well.  Many of the
> more powerful techniques are basically impossible without garbage
> collection.
>
> But I think this largely comes down to standard library design. Java,
> for example, is a pretty okay language from a syntax perspective.  The
> problem with it is more that doing anything with the standard library
> requires generating tons of often temporary objects.  In the server
> programming realm, an unbelievable amount of effort has been put into
> working around this particular problem (look at what the Netty group has
> been doing, for example).  So it's not so much that the language
> supports garbage collection as that the established programming paradigm
> encourages you to lean heavily on it.
>
> By allowing manual memory management, D is far closer to C++. The
> problem is that, like Java, many APIs in the standard library are
> written in such a way that memory allocations are unavoidable.  However,
> it doesn't have to be this way.  An essential design rule for Tango, for
> example, was to perform no hidden allocations anywhere.  And it's
> completely possible with Tango to write an application that doesn't
> allocate at all once things are up and running.  With Phobos... not so
> much.
>
> In short, I think that a crucial factor affecting the perception of a
> language is its standard library.  It stands as a template for how code
> in that language is intended to be written, and is the framework from
> which essentially all applications are built. Breaking from this tends
> to be difficult to the point of where you're really better off looking
> for a different language that suits your needs better.
>
> I think Java is in a weird spot in that it's so deeply entrenched at
> this point that many think it's easier to try and force people to change
> their programming habits than it is to get them to use a different
> language.  Though encouraging a transition to a compatible language with
> better fundamentals is probably preferable (Scala?).
>
> C++ is kind of in the same situation, which I guess is why some feel
> that C++ interop might be a good thing.  But realistically, working with
> a truly hybrid code base only serves to further complicate things when
> the motivating goal is simplification. It's typically far preferable to
> simply have communicating agents written in different languages that all
> talk the same protocol. That C++ app can go into maintenance mode and
> the Java, D, and whatever other new stuff just talks to it via a socket
> connection and then shivers and washes its hands when done.

It has been acknowledged that it was a mistake not to allow better control in Java where to place the data, for the last mile in performance.

This is why the major focus in Java 9+ are value types, control over array layouts, a new FFI interface and promotion of unsafe to public API.

http://www.oracle.com/technetwork/java/javase/community/jlssessions-2255337.html

This is a consequence of Java's use in big data and high performance trading systems.

D's advantage is that (except for current GC), it offers today what Java can only offer in the next revision, or even later if not all features happen to be 9 ready.

--
Paulo

On Thu, 11 Sep 2014 15:54:17 +0000
Andrey Lifanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> What do you mean? Some sort of memory leak?
no, i meat that predictability is lost there. and with single-linked lists, for example, freeing list head can take big amount of time too if the list is sufficiently long.

what D really needs is GC that will not stopping the world on collecting. you will be able to separate threads that allocating from threads that not, and non-allocating threads will work without pauses. then 'worker' threads can use lists of free objects almost without GC hits.

On 09/11/2014 09:59 AM, ketmar via Digitalmars-d wrote:

> On Thu, 11 Sep 2014 15:54:17 +0000
> Andrey Lifanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> What do you mean? Some sort of memory leak?
> no, i meat that predictability is lost there. and with single-linked
> lists, for example, freeing list head can take big amount of time too
> if the list is sufficiently long.

In support of your point, one of Bartosz Milewski's blog posts[1] has a link to a paper[2] where he says "There is actual research showing that the two approaches are just two sides of the same coin."

Ali

[1] http://bartoszmilewski.com/2013/09/19/edward-chands/

[2] http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

Thank you all for replies!

I'm not saying that GC is evil. I just want to have different options and more control, when this is required. If D offered such choice, many good C++ programmers would have certainly considered D as a perfect alternative to C++.

D states that there is no strict and dogmatic rules that it follows about programming languages paradigms. And that it is a general purpose language. So I think it would be nice to have more options of how we can manage memory.

I will continue investigation and certainly inform you if it ends with something useful.

You know, currently I spend most of my time programming in ObjC, but I really love C, C++ and D.

Since the Clang Compiler, ObjC dropped the GC entirely. Yes, that's right, no GC at all. And, in fact, it does support concurrent programming and everything else. The magic behind it is ARC - Automated Reference Counting (http://clang.llvm.org/docs/AutomaticReferenceCounting.html): the compiler analyzes your code, figures out object scopes and sets the correct calls to retain/release/autorelease (for those who are not familiar with ObjC, pointers are mostly reference counted). So there is no need for a GC and all its complications.

In addition to that, Rusty also has an approach like ObjC called Region Pointers and objects' Lifetime (http://doc.rust-lang.org/guide-pointers.html#boxes). The idea is the same, but, depending on the type of the pointer, the compiler may add a call for freeing or for decrementing a pointer reference counter.

Finally, it looks like there is a language called Cyclone that goes the same way (paper here: http://www.cs.umd.edu/projects/cyclone/papers/cyclone-regions.pdf)

Since I read Andrei's book, D Programming Language, I've been asking myself why D does not go this way...

Anyone knows about a good reason for that?

On Thursday, 11 September 2014 at 18:04:06 UTC, Andrey Lifanov wrote:
> Thank you all for replies!
>
> I'm not saying that GC is evil. I just want to have different options and more control, when this is required. If D offered such choice, many good C++ programmers would have certainly considered D as a perfect alternative to C++.
>
> D states that there is no strict and dogmatic rules that it follows about programming languages paradigms. And that it is a general purpose language. So I think it would be nice to have more options of how we can manage memory.
>
> I will continue investigation and certainly inform you if it ends with something useful.

On Thu, 11 Sep 2014 18:32:09 +0000
Daniel Alves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> compiler analyzes your code, figures out object scopes and sets the correct calls to retain/release/autorelease
this *is* GC. it's just hidden behind compiler magic and can't be changed without altering the compiler.

On Thu, 11 Sep 2014 18:04:05 +0000
Andrey Lifanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Thank you all for replies!
> 
> I'm not saying that GC is evil. I just want to have different options and more control, when this is required. If D offered such choice
but D *is* offering such choice.

On Thursday, 11 September 2014 at 18:32:10 UTC, Daniel Alves wrote:
> You know, currently I spend most of my time programming in ObjC, but I really love C, C++ and D.
>
> Since the Clang Compiler, ObjC dropped the GC entirely. Yes, that's right, no GC at all. And, in fact, it does support concurrent programming and everything else. The magic behind it is ARC - Automated Reference Counting (http://clang.llvm.org/docs/AutomaticReferenceCounting.html): the compiler analyzes your code, figures out object scopes and sets the correct calls to retain/release/autorelease (for those who are not familiar with ObjC, pointers are mostly reference counted). So there is no need for a GC and all its complications.
>
> In addition to that, Rusty also has an approach like ObjC called Region Pointers and objects' Lifetime (http://doc.rust-lang.org/guide-pointers.html#boxes). The idea is the same, but, depending on the type of the pointer, the compiler may add a call for freeing or for decrementing a pointer reference counter.
>
> Finally, it looks like there is a language called Cyclone that goes the same way (paper here: http://www.cs.umd.edu/projects/cyclone/papers/cyclone-regions.pdf)
>
> Since I read Andrei's book, D Programming Language, I've been asking myself why D does not go this way...
>
> Anyone knows about a good reason for that?
>
> On Thursday, 11 September 2014 at 18:04:06 UTC, Andrey Lifanov wrote:
>> Thank you all for replies!
>>
>> I'm not saying that GC is evil. I just want to have different options and more control, when this is required. If D offered such choice, many good C++ programmers would have certainly considered D as a perfect alternative to C++.
>>
>> D states that there is no strict and dogmatic rules that it follows about programming languages paradigms. And that it is a general purpose language. So I think it would be nice to have more options of how we can manage memory.
>>
>> I will continue investigation and certainly inform you if it ends with something useful.

Here are a few of the bazillion threads that have discussed the topic:
http://forum.dlang.org/thread/ljrm0d$28vf$1@digitalmars.com?page=1
http://forum.dlang.org/thread/lphnen$1ml7$1@digitalmars.com?page=1
http://forum.dlang.org/thread/outhxagpohmodjnkzzol@forum.dlang.org

On Thursday, 11 September 2014 at 18:32:10 UTC, Daniel Alves wrote:
> You know, currently I spend most of my time programming in ObjC, but I really love C, C++ and D.
>
> Since the Clang Compiler, ObjC dropped the GC entirely. Yes, that's right, no GC at all. And, in fact, it does support concurrent programming and everything else. The magic behind it is ARC - Automated Reference Counting (http://clang.llvm.org/docs/AutomaticReferenceCounting.html): the compiler analyzes your code, figures out object scopes and sets the correct calls to retain/release/autorelease (for those who are not familiar with ObjC, pointers are mostly reference counted). So there is no need for a GC and all its complications.
>
> In addition to that, Rusty also has an approach like ObjC called Region Pointers and objects' Lifetime (http://doc.rust-lang.org/guide-pointers.html#boxes). The idea is the same, but, depending on the type of the pointer, the compiler may add a call for freeing or for decrementing a pointer reference counter.
>
> Finally, it looks like there is a language called Cyclone that goes the same way (paper here: http://www.cs.umd.edu/projects/cyclone/papers/cyclone-regions.pdf)
>
> Since I read Andrei's book, D Programming Language, I've been asking myself why D does not go this way...
>
> Anyone knows about a good reason for that?

There have been some long threads about ARC, including this one from a couple months ago:

http://forum.dlang.org/thread/mailman.2370.1402931804.2907.digitalmars-d@puremagic.com

Walter doesn't think ARC can be done efficiently.