Getting completely (I mean ENTIRELY) rid off GC

[Paulo Pinto via Digitalmars-d]

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