Truffle and mlvm
Mark Roos
mroos at roos.com
Sun Aug 31 20:54:34 UTC 2014
Thomas
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
victory.
regards
mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140831/89e16356/attachment.html>
More information about the mlvm-dev
mailing list