Using V8 for other languages

--===============0341282773==
Content-Type: multipart/alternative; 
	boundary="----=_Part_15995_13047612.1220421652605"

------=_Part_15995_13047612.1220421652605
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

A little more info on V8.

I talked briefly with Lars Bak and Robert Griesemer today, (both are on the
V8 team, and Lars is the lead) and got a little bit of their perspective on
using V8 for other languages.  As was to be expected, the VM is targeted to
JavaScript semantics, and given the gnarliness of those semantics, there are
a few caveats to think about.

   - V8 will get faster as it matures, of course, however:
   - There will be issues around things like immediate object semantics,
   which don't exactly match up with any other language.  Yucky JavaScript!
   - A bigger long-term performance issue is that given the dynamic nature
   of JavaScript objects (i.e. adding/removing slots on the fly) there
   apparently isn't any way around adding an additional indirection to deal
   with the object size changing dynamically.  That is something that will just
   have to be lived with.  I was hoping they had some magic there, but
   apparently not.

I'm sure that these sorts of things can be worked around, but they do mean
that V8 will never in its pure form quite reach the pinnacle of theoretical
performance possible for a VM targeted specifically to Smalltalk etc.  So it
won't be as fast as Strongtalk, although it may get fairly close to
VisualWorks performance.

Nonetheless, I still think it or some derivative will quickly become the
dominant dynamic language VM, for the following reasons:

   - Given who the developers are, and with Google behind it, it will be the
   fastest JavaScript VM for a long time to come.
   - For the same reason, it will be reliable and secure (as much as it can
   be, anyway; nothing is perfect).
   - It will be supported on the three major platforms (Windows, Linux,
   Mac).
   - It can be used with other browsers, so I'm sure it will be ported to
   Firefox (if only as an option).  Some or all of the other browsers may also
   adopt it, given that it will have a very hard-to-overcome performance
   advantage (these sorts of VMs can't be pulled out of a hat).  Although MS
   and maybe Safari may have too much of a Not Invented Here problem with it,
   as well as standards war issues.
   - those things, plus the other architectural advantages it brings, will
   make it a primary target for serious web app development, esp. Google apps.
   - So it will be ubiquitous

So it will be an irresistible platform for other dynamic languages, even if
they could theoretically run a bit faster on a custom VM.  Remember it will
still be a lot easier to run other dynamic languages on JavaScript than it
is to run them on Java, since at least JavaScript is fully dynamic, unlike
Java.

And remember, the bottom line is that it is a clean, supported,
state-of-the-art multi-threaded design that is fully open-source.  So as a
last resort, there is always FORK!

-Dave

------=_Part_15995_13047612.1220421652605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr"><div>A little more info on V8.<br><br>I talked briefly with Lars Bak and Robert Griesemer today, (both are on the V8 team, and Lars is the lead) and got a little bit of their perspective on using V8 for other languages.&nbsp; As was to be expected, the VM is targeted to JavaScript semantics, and given the gnarliness of those semantics, there are a few caveats to think about.<br>
<ul><li>V8 will get faster as it matures, of course, however:<br></li><li>There will be issues around things like immediate object semantics, which don&#39;t exactly match up with any other language.&nbsp; Yucky JavaScript!<br>
</li><li>A bigger long-term performance issue is that given the dynamic nature of JavaScript objects (i.e. adding/removing slots on the fly) there apparently isn&#39;t any way around adding an additional indirection to deal with the object size changing dynamically.&nbsp; That is something that will just have to be lived with.&nbsp; I was hoping they had some magic there, but apparently not.<br>
</li></ul></div>I&#39;m sure that these sorts of things can be worked around, but they do mean that V8 will never in its pure form quite reach the pinnacle of theoretical performance possible for a VM targeted specifically to Smalltalk etc.&nbsp; So it won&#39;t be as fast as Strongtalk, although it may get fairly close to VisualWorks performance.<br>
<br>Nonetheless, I still think it or some derivative will quickly become the dominant dynamic language VM, for the following reasons:<br><ul><li>Given who the developers are, and with Google behind it, it will be the fastest JavaScript VM for a long time to come.</li>
<li>For the same reason, it will be reliable and secure (as much as it can be, anyway; nothing is perfect).<br></li><li>It will be supported on the three major platforms (Windows, Linux, Mac).&nbsp; <br></li><li>It can be used with other browsers, so I&#39;m sure it will be ported to Firefox (if only as an option).&nbsp; Some or all of the other browsers may also adopt it, given that it will have a very hard-to-overcome performance advantage (these sorts of VMs can&#39;t be pulled out of a hat).&nbsp; Although MS and maybe Safari may have too much of a Not Invented Here problem with it, as well as standards war issues.<br>
</li><li>those things, plus the other architectural advantages it brings, will make it a primary target for serious web app development, esp. Google apps.</li><li>So it will be ubiquitous</li></ul>So it will be an irresistible platform for other dynamic languages, even if they could theoretically run a bit faster on a custom VM.&nbsp; Remember it will still be a lot easier to run other dynamic languages on JavaScript than it is to run them on Java, since at least JavaScript is fully dynamic, unlike Java.<br>
<br>And remember, the bottom line is that it is a clean, supported, state-of-the-art multi-threaded design that is fully open-source.&nbsp; So as a last resort, there is always FORK!<br><br>-Dave<br></div>

------=_Part_15995_13047612.1220421652605--

--===============0341282773==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



--===============0341282773==--