D vs Java

[Jari-Matti Mäkelä]

Thomas Kuehne wrote:
> One huge advantage of VMs is their design:
> * lot's of prior experiences with all sorts of architectures and
> libs

Well, this might only be a matter of time.

> 
> * a clean sheet, thus no cludges for supporting applications from
> the parent architecture
> 

Actually D is doing very well here too. A normal end-user application
coder doesn't need to care about all the low level stuff.

> * a strong seperation between normal applications and the used
> hardware(including the CPU) -> "smart" phone applications

True.

> * most important: the potential to design according to todays
> requirements and available technology instead of those from
> the 70th and 80th
> (the C99 standart only specifies how to access files but not
> how to list directories?!)

D is able to fix most of these issues without any VMs. Even though you
have a decent VM today, tomorrow someone will invent a new thingie that
suddenly everybody needs. Updating an existing VM/language isn't that
painless. Java has a huge load of deprecated junk for backwards
compatibility.

> 
> There are domains where VMs make sence, but you are right
> a secure modular kernel could be used in most places where
> Java and .NET are currently used. One nice point about
> the Java and .NET runtimes are the large amount of
> OS/architecture agnostic tools/objects/functions.
> 

Certainly there are domains where a VM'ed language suits better than
bare metal access alternative but unfortunately this "managed code" is
often used excessively.

If I recall correctly, some vendors even use C# in basic end-user
GUI-based configurators for device drivers. These programs usually
require you to reboot, when you change something. I cannot see, why a VM
written in C + a wrapper library using C/C++ GUI-bindings + a byte code
program performs any better than a modular kernel + script interpreter
and GUI libraries written in D + a high level configurator script. The
latter one starts up much faster, eats only a small fraction of memory
compared to the bloaty VM-version and is actually more light-weight in
terms of LOC.

-- 
Jari-Matti