D vs Java

[Matthias Spycher]

Walter Bright wrote:
> I'm no expert on Java programming, but I get this question a lot: "What 
> compelling reason does D have that would entice a Java programmer to switch 
> to D?"
> 
> I know several of you have come to D from Java, and are expert Java 
> programmers, so you folks' reasons would be very valuable. 
> 
> 

I agree with Andrew that D and Java belong in separate categories. Java 
is intended for managed environments where the guts of the runtime are 
not exposed to the programmer. The object model is simple, the dynamic 
linking mechanism with class loaders is very powerful, and dynamic 
compilation achieves performance that is acceptable for many applications.

If you look at just the language, it would be very easy to say D is 
competitive or superior. But if you look at the whole application 
life-cycle from specification, development, deployment, management, 
maintenance, evolution, etc., and the tools that support you in this 
cycle; D has quite a ways to go -- not so much the language, but the 
ecosystem around it.

I do believe that, for certain applications, a dynamic compiler will at 
some point do a better job of optimizing code than a static compiler. Why?

1. A dynamic compiler knows about the architecture of the machine, e.g. 
cache sizes; and the profile of the running application, e.g. I/O 
boundedness. The data path is likely to be the main bottleneck in coming 
years.

2. Languages like Java have the advantage that they don't expose the 
actual layout of objects in memory to the programmer. Any language with 
pointers has a disadvantage in the context of dynamic optimization.

3. Multicore/multithreaded systems will provide for enough computational 
bandwidth for dynamic compilers and GCs to run in parallel with the 
programs they operate on. Performance degradation due to compilation at 
runtime will become a moot point on server systems very soon.

4. The ability to run multiple applications in the same runtime context; 
i.e. sharing the heap, the GC and the dynamically compiled bits of code; 
will reduce the overhead (which today is clearly a big issue for certain 
applications). Such a feature will be more easily implemented for a 
language like Java than D.

Scalability. Java scales quite well to very large projects. Applications 
with millions of lines of code built by hundreds of developers (with 
different skill sets) are not out of the ordinary. If D can achieve this 
scalability (with the right tools, of course) then it will have come a 
long way. C/C++ do not scale this well primarily because they are 
system-dependent, have weaker semantics, limited library functionality, 
expose memory to the programmer and don't support garbage collection. 
Ownership patterns in large code bases are lost on the masses, and 
programming in the large becomes increasingly a breeding ground for 
dictatorships. One might argue Java is a mediocre programming language, 
but most programmers are mediocre, so less is more...

Mobility. If you were a Comcast or a Vodafone, would you like to manage 
native downloadable applications for each and every gadget architecture 
that will appear on the planet. The ARM Cortex A8 architecture has this 
Jazelle RTC technology which will help byte-code apps scale on mobile, 
embedded systems. The infrastructure to manage native binaries is too 
expensive (not to mention fragile) and the performance degradation for 
byte code apps will be addressed (in hardware, if necessary).

The choice for me will be to use D instead of C or C++ when I need to 
program at the system level -- when it's ready. I certainly think D is 
on the right track, so keep up the good work. IMHO, Java/C# are on a 
different track.

Matthias