The biggest reason would be the "native" interoperability. No FFIs because while you could call it a language it's more accurately syntax sugar.

Another reason with Rust at least. Rusthon can make the same memory guarantees as Rust.

Personally I wish this was done with Ruby.. But then again I'm not writing it myself, so I can't really complain.

A random last thought, it would be really something if Rust could formally prove its memory safety and then push that whole system of lifetimes and borrow checks into LLVM or a similar abstraction on top of LLVM. Because Rust as a compiler target is very interesting but it wasn't really built for that.

Pyston is a very exciting project. The commit velocity on github seems quite high [0]. Here's the latest status update on their blog, for those interested: http://blog.pyston.org/2014/11/21/pyston-status-update/

[0] https://github.com/dropbox/pyston/graphs/commit-activity

Except it's not targeting Python 3

Pypy is pushing towards full 3.4 slowly, which is good because I want some of that Juicy STM support in my web apps.

You are one of few concerned with Python3 targets. Pyston, PyPy are all mostly Python(2) projects. PyPy3 does exist, but it's considered beta and not recommended for production use as PyPy is.

Python(2) code/libraries will mainly survive on PyPy/Pyston going forward. With stuff like Nim and Rusthon, I think something like those will carry the torch forward after Python(2), rather than Python3.