D vs VM-based platforms

[Benji Smith]

Walter Bright wrote:
> I just don't get the reason for a VM. It seems like a solution looking 
> for a problem.

Some of the benefits of using a VM platform:

1) Dynamic classloading. Linking is greatly simplified, and my code 
doesn't need to be written differently depending on whether I'm linking 
dynamically or statically.

2) Better tools for profiling, debugging, reflection, and runtime 
instrumentation than are typically available for natively-compiled 
languages.

3) Better memory management: with the memory manager located in the VM, 
rather than in the application code, the collection of garbage is much 
more well-defined. Since all classes are loaded into the same VM 
instance, there's only a single heap. Consequently, there's never an 
issue of what happens when an object passes from one module to another 
(as can be the case when a native library passes an object into the main 
application, or vice versa).

4) Better security/sandboxing. If you write a pluggable application in 
C++, how will you restrict plugin authors from monkeying with your 
application data structures? In the JVM or the CLR, the VM provides 
security mechanisms to restrict the functionality of sandboxed code. A 
particular CLR assembly might, for example, be restricted from accessing 
the file system or the network connection. You can't do that with native 
code.

Sure, it's possible for natively-compiled languages to offer most of the 
same bells and whistles as dynamic languages or VM-based platforms. But, 
in the real world, those abstractions are usually difficult to implement 
in native code, so they become available much more readily in virtual 
machine.

--benji