D vs VM-based platforms

[Walter Bright]

Brad Roberts wrote:
> Benji Smith wrote:
>> 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.

That's an attribute of the language, not the VM. COM does the same thing 
with natively compiled languages.

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

I attribute this to two things, none of which are a characteristic of a VM:

1) Java is a very easy language to parse, with well defined semantics. 
This makes it easy to develop such tools for it. C++, on the other hand, 
is disastrously difficult to parse.

2) The two VMs out there have billions and billions of dollars sunk into 
them to create tools, no matter how easy/hard that might be.

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

1) I wrote a GC for Java, back in the day. Doing a good GC is dependent 
on the right language semantics, having a VM has nothing to do with it. 
D works with add on DLLs by sharing a single instance of the GC.


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

Every single VM based system, from javascript to Word macros, has turned 
into a vector for compromising a system. That's why I run email with 
javascript, etc., all turned off. It's why I don't use Word. I know 
about the promises of security, but I don't believe it holds up in practice.


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

I believe you are seeing the effects of billions of dollars being 
invested in those VMs, not any fundamental advantage.