Getting completely (I mean ENTIRELY) rid off GC

[Sean Kelly via Digitalmars-d]

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.