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
