Truffle and mlvm

Mark Roos mroos at
Sun Aug 31 20:54:34 UTC 2014


You state 
        ...a new language implementation platform.

and then
        I strongly believe that Truffle is the best currently available 
vehicle to make 
        Ruby competitive in terms of performance with node.js.

If the goal is to create a 'new language' platform then why not create a 
new language with it?
What drove first the PYPY group and now you in deciding to make a faster 
Ruby rather than a
better language?  Probably because the first 80% of a port is easy and you 
get good press.  After
that it looks like the interest fades.  While the first 20% of a new 
language is hard and the 
critics are brutal.

There seems to be a lot of new language work these days.  If your goal is 
not a new
Java+jvm, and I say this because I have not see an effort to reinvent 
these in Truffle, then why not 
make it your goal to enable the creation of great new languages?  Instead 
the interest seems to
be in showing that extreme personal effort can conquer the corner cases ( 
or not ) of popular ancient 
languages.  A look at the history of PYPY could give quite some insight 
into the barriers.

It appears that with the advent of co-processors ( gpus and custom fpga 
addons ) and value types that
the need for customized method compilation  will be necessary to take full 
advantage.  Being able to make
intrinsic methods dynamically rather than via jni or jdk customization 
seems appealing.   But forcing
a complete change away from what in in use today is a lot to ask.  I see 
the Sumatra project seems to
be going this way but it looks like they have to move to Graal to do it.

In the end all code starts with a single method send.  That one method 
could be the only method and
could be compiled using Truffle.  If that were to happen you could declare 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the mlvm-dev mailing list