It's a good idea. Many projects are converging on RPython as a sort of implementation shortcut. This will accomplish two things: (a) let language and tool designers focus their creativity on important stuff rather that low-level crud that has to be there; (b) result in improvements to RPython toolchain as a side effect. Author said similar stuff in the Conclusion section.

I think people getting to low-level details for performance reasons would benefit from thoroughly studying the faster LISP compilers. They've been crazy efficient for their level of flexibility. There's undoubtedly tricks they use that could be applied to compiling or interpreting modern scripting languages. I thought about making a source-to-source compiler from JavaScript to a LISP/scheme subset (fastest parts) to leverage their compilers. Lack the time unfortunately.

I wrote a couple of blog posts a few years back about RPython (http://www.maori.geek.nz/post/rpython_compiling_python_to_c_... http://www.maori.geek.nz/post/rpython_is_not_a_language_an_i...) where I implemented a Boolean Satifiability Solver in it. The biggest problem with RPython is there is no definition of a language, it is a tool chain, and it can get very difficult to tell whether what you are writing will even compile. It was very fast though.