On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
- It's quite clear that D was influenced a lot by Java at some
point, which led to borrowing (copying?) a lot of Java features
that may not appeal to everyone.
Have you observed a human to exist who has complained about a
specific feature in D that is similar to a feature in Java?
Relaying their complaints would be much more useful.
- The amount of trickeries required to avoid the GC and do
manual memory management are not pleasant and counter
productive. I feel they defeat any productivity gains the
language was supposed to offer.
Since so much of C++'s coding style revolves around memory
management, the idea that you might be able to avoid manual
memory management and still not see a giant reduction in
performance is transformative. It means writing code in an
entirely different style. And because Java is the point of
comparison for using a garbage collector, it's easy to think that
a GC is impossibly inefficient. But that's because Java abuses
its GC so heavily (and because Java came out in an era when
having 64MB of RAM on a home computer was pretty swish).
Let's compare with how D uses the GC. Here's an example of code
that I wrote in the most obvious way possible that is more
efficient than the equivalent in C++, specifically because of the
garbage collector:
https://github.com/dhasenan/subtex
The only nods to performance in that are when I have various
Appenders reserve some space in advance.
On my 410KB reference document, this completes in 50ms. (That's
90ms faster than a Java "hello world" program.) I ported it to C#
for comparison, and it took over one second. I ran a GC profiler
and discovered that it allocated 4GB in string data.
The D version, by contrast, allocates a total of 12MB, runs three
GC collections, and has a total pause time under 1ms. (If I add a
call to `GC.collect()` just before the application exits, the
total pause time exceeds 1ms but is still below 2ms.)
You might say that I could use C++ style manual memory management
and get even better performance. And you'd be wrong.
The culprit for the C# version's poor performance was
System.String.Substring, which allocates a copy of its input
data. So "Hello world".Substring(5) creates a new char* pointing
at a new memory allocation containing "Hello\0". C++'s
std::string does the same thing. So if I reimplemented subtex
naively in C++, its performance would be closer to the C# version
than to the D version.
I could probably get slightly better performance than the D
version by writing a special `stringslice` struct. But that's a
lot of work, and it's currently just barely fast enough that I
realize that I've actually run the command instead of my shell
inexplicably swallowing it.
On the whole, it sounds like you don't like D because it's not
C++. Which is fine, but D isn't going to become C++.
