<font size=2 face="sans-serif">Thomas</font>
<br>
<br><font size=2 face="sans-serif">You state </font>
<br><font size=3>        ...a new language
implementation platform.</font>
<br>
<br><font size=2 face="sans-serif">and then</font>
<br><font size=3>        I strongly believe
that Truffle is the best currently available vehicle to make </font>
<br><font size=3>        Ruby competitive in
terms of performance with node.js.</font>
<br>
<br><font size=2 face="sans-serif">If the goal is to create a 'new language'
platform then why not create a new language with it?</font>
<br><font size=2 face="sans-serif">What drove first the PYPY group and
now you in deciding to make a faster Ruby rather than a</font>
<br><font size=2 face="sans-serif">better language?  Probably because
the first 80% of a port is easy and you get good press.  After</font>
<br><font size=2 face="sans-serif">that it looks like the interest fades.
 While the first 20% of a new language is hard and the </font>
<br><font size=2 face="sans-serif">critics are brutal.</font>
<br>
<br><font size=2 face="sans-serif">There seems to be a lot of new language
work these days.  If your goal is not a new</font>
<br><font size=2 face="sans-serif">Java+jvm, and I say this because I have
not see an effort to reinvent these in Truffle, then why not </font>
<br><font size=2 face="sans-serif">make it your goal to enable the creation
of great new languages?  Instead the interest seems to</font>
<br><font size=2 face="sans-serif">be in showing that extreme personal
effort can conquer the corner cases ( or not ) of popular ancient </font>
<br><font size=2 face="sans-serif">languages.  A look at the history
of PYPY could give quite some insight into the barriers.</font>
<br>
<br><font size=2 face="sans-serif">It appears that with the advent of co-processors
( gpus and custom fpga addons ) and value types that</font>
<br><font size=2 face="sans-serif">the need for customized method compilation
 will be necessary to take full advantage.  Being able to make</font>
<br><font size=2 face="sans-serif">intrinsic methods dynamically rather
than via jni or jdk customization seems appealing.   But forcing</font>
<br><font size=2 face="sans-serif">a complete change away from what in
in use today is a lot to ask.  I see the Sumatra project seems to</font>
<br><font size=2 face="sans-serif">be going this way but it looks like
they have to move to Graal to do it.</font>
<br>
<br><font size=2 face="sans-serif">In the end all code starts with a single
method send.  That one method could be the only method and</font>
<br><font size=2 face="sans-serif">could be compiled using Truffle.  If
that were to happen you could declare victory.</font>
<br>
<br><font size=2 face="sans-serif">regards</font>
<br><font size=2 face="sans-serif">mark</font>
<br>
<br>
<br>