Coolest D features

[Walter Bright]

Mike Parker wrote:
> Being a long time Java programmer, I strongly disagree with you and 
> Waldemar both. Speed is only an issue for people who don't use Java, or 
> for those who don't really know how to properly write software with it. 
> Most Java programmers I know, myself included, call the "Java is slow" 
> mantra a myth. Java *used to* be slow, true. Today, it's possible to 
> code a clunky app in Java if you don't know what you are doing. But the 
> reality is that it's plenty fast in the general case. Plus, Java 
> programmers swear by runtime compilation. And each release of Sun's 
> Hotspot compiler, coupled with bug fixes and enhancements in the 
> standard APIs, ups performance. So if you want to woo them, focusing on 
> speed is not the way to do it. That would be more likely to turn them 
> off, if not make them outright perturbed (oh, here we go again, another 
> "Java is slow" moron).

I haven't worked with Java for over 10 years now. But in March I 
attended "Java Performance Myths" by Brian Goetz, who is very 
knowledgeable about getting the most out of Java. He indicated that Java 
  needed another 10 years before it would be able to consistently match 
C toe to toe. And this is happening despite years of massive investment 
in Java by lot of very smart people, just to approach what relatively 
simple C compilers can do. This to me indicates there's a fundamental 
problem with Java.

I think the problem is that Java is just lacking in some needed features 
- like a full set of basic types, simple aggregates, out parameters, 
etc. The alternatives are computationally expensive, and so the 
optimizer has a lot of work to do to reverse engineer them and figure 
out that all the programmer was doing was a workaround for a POD stack 
aggregate.

Java also has a few millstones that make things difficult for optimizers 
- the required array bounds checking, the VM, etc.

C++, much promoted for its efficiency, has a subtle problem with 
efficiency. We all know that the biggest gains in efficiency come from 
algorithmic improvements. But C++'s strength is in optimizing not the 
algorithms, but the micro-optimization details of implementing them. C++ 
code tends to get so complex that once we get it to work, we dare not go 
tinkering with the overall algorithm, but just concentrate on twiddling 
with the micro-optimizations.

I discovered this when working on DMDScript. I had spent a great deal of 
time tinkering with the details of the C++ version trying to make it go 
faster. Then I translated it to D, and found myself instead of tinkering 
with the low level details, I was tinkering with the algorithms. With a 
few changes there, that would have been hard to retrofit into the C++ 
code, I had it running faster than the C++ one.

And that may be D's efficiency trump card over C++ - it's much easier to 
modify existing, working code in ways that are too risky to do with C++.