Thoughts about D

[Neia Neutuladh]

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++.