[ctoshok]

The use of "self-hosting" was addressed in post. I think its use is actually right on the mark, but will grant you that it's slightly different than its use in the context of a static compiler written in the target language.

It basically means "able to host its own development". This means something different in different contexts, e.g. JS JITs "self-host" when some part of their builtin code is written in JS. We share that property with JS JITs, but in this particular case it means we can host our own build/test infrastructure. So we're using pyston to develop pyston. ergo, "self-hosting (qualified)."

---

We're definitely slower than pypy at present - we're only a small fraction faster than cpython after all on our benchmarks, and pypy is scary fast :)

I think we're still in the part of our work where the answer to the "big win with this approach" question is "we don't know." We're confident that we can/will be much faster than we are now, but we have different constraints than pypy, so it will always be something of an apples/oranges comparison.

[eiopa]

I see. I think it's a huge stretch :) That's like Go claiming they are self-hosting because some of their tools are written in Go.

On a related note, I have to say that I still don't understand the point of this project. Were you guys unhappy with pypy's performance or development?

I understand that in theory, the approach you guys are taking is incompatible with pypy's, but I can't help but wonder how thing would play out if you Dropbox put their weight behind PyPy. Maybe it could've been the start of every Python programmer's wet dream: Python 2.8.

[rian]

You really could have just said "dream."

[eiopa]

I think "wet dream" captures it better.

[vidarh]

That's the first time I've seen someone use self-hosting in that manner, or in the manner you describe in your examples.

To me it was totally misleading.