D vs. C#

[Walter Bright]

Vladimir Panteleev wrote:
> Indeed. Infact, most of the issues I mentioned can be solved by
> distributing source code instead of intermediary bytecode. Actually,
> if you compare the Java/.NET VM with a hypothetical system which
> compiles the source code and runs the binary on the fly, the
> difference is pretty low - it's just that bytecode is one level lower
> than source code (and source code parsing/lexing would slow down
> compilation to native code by some degree).

To some degree, yes. You can address this, though, by pre-tokenizing the 
source.

> I don't think it would be hard to turn D into a VM just like .NET -
> just split the front-end from the back-end, make the front-end
> serialize the AST and distribute a back-end that reads ASTs, "JITs"
> them, links to Phobos/other libraries and runs them. You could even
> scan the AST for unsafe code (pointers, some types of casts), add
> that with forced bounds checking, and you have a "safe" D
> VM/compiler. So, I'd like to ask - what exactly are we debating
> again? :)
> 
> When comparing VMs (systems that compile to bytecode) to just
> distributing the source code (potentially wrapping it in a bundle or
> framework that can automatically compile and run the source for the
> user), the later inherits all the disadvantages of the VM (slow on
> first start, as the source code has to be compiled; the source or
> some other high-level source structures can be extracted; etc.). The
> only obvious advantage is that the source is readily available in
> case it's necessary to debug the application, but Java already has
> the option to include the source in the .jar file (although this
> causes it to include code in both bytecode and source).
> 
> If we assume that all bytecode or source is compiled before it's ran
> (nothing is interpreted), as should happen in a "perfect" VM, the
> term "VM" loses much of its original meaning. The only thing left is
> the restrictions imposed on the language (no unsafe constructs like
> pointers) and means to operate on the AST (reflection, code
> generation, etc.) Taking that into consideration, comparing a perfect
> "VM" with distributing native code seems to make slow start-up and
> the bulky VM runtime the only disadvantages of using VMs. (Have I
> abstractized so much that I'm forgetting something important here?)

I don't think you've forgotten anything important.

> 
>>> 5) it's much easier to provide security/isolation for VM
>>> languages. Although native code isolation can be done using
>>> hardware, it's complicated and inefficient.
>> The virtualization hardware works very well! It's complex, but it
>> is far more efficient than a VM is. In fact, you're likely to be
>> running on a hardware virtualized machine anyway!
> 
> Unfortunately, virtualization extensions are not available on all
> platforms - and implementing sandboxing on platforms where it's not
> supported by hardware would be quite complicated (involving
> disassembly, recompilation or interpretation).

I agree, but not in the case where source code is distributed and the 
compiler is controlled by the box, not the programmer.

> VirtualBox is a nice
> part-open-source virtualization product, and they stated that the
> software virtualization they implemented is faster than today's
> hardware virtualization.

I find that hard to believe.


>>> This allows VM languages to be safely embedded in places such as
>>> web pages (Flash for ActionScript, applets for Java, Silverlight
>>> for .NET).
>> It is not necessary to have a VM to achieve this. If you design a 
>> language that does not have arbitrary pointers, and you control the
>> code generation, you can sandbox it in software every bit as
>> effectively. This is why, for example, the Java JITs don't
>> compromise their security model.
> 
> This requires that the code is given at a level high enough where
> this is enforceable - that is, either at source or bytecode/AST
> level.

Right.

> I also thought of another point (though it only stands against
> distributing native code binaries, not self-compiling source code): 
> 6) Bytecode can be compiled to optimized code for the specific
> environment it is run on (processor vendor and family). It's not a
> big plus, just a "nice" advantage.

That's often been touted, but it doesn't seem to produce much in the way 
of real results.