That’s a false dilemma. We’ve had almost three decades to optimize CPython. It will take a while to catch up.
Assuming that was actively pursued. But if it was, all those other projects (Unladden Swallow, Dropbox's Python project, PyPy, etc, whose intend was exactly to make Python faster, wouldn't have been started).
It's not remarkably slow as long as you compare apples to apples, that is non-jitted vm-interpreters.
Jits pay a steep complexity- (and hence maintenance) price for their performance that should be taken into account when comparing.
Designing a significantly faster interpreter with comparable features is non-trivial from my experience [0].
> [Performance] isn't [...] one of the selling points of Rust
or
> this [...] software has been implemented poorly
It sounds like you're maligning Rust (isn't keeping promises) or RustPython (is implemented poorly), and it's easy to read "implemented poorly" as an attack on the implementers.
I really don't know how slow it is, I've not done benchmarks, but given that Rust is supposed to be efficient, it certainly can't be that slow, unless the implementation is really poor, I guess. I'm not saying it is because I don't know. If anyone has done benchmarks, please do share!
The reason for why I got the idea that it is slow, is that I believed the parent[1], and people have repeatedly claimed that CPython is slow.
[1] "to eventually get the same or better performance as CPython."
I assume this means that it is slower than CPython, and CPython is already extremely slow according to some people even on this page.
Sorry for the confusion. :)
One thing to consider is that CPython isn't slow because of the language it's written in, but because of optimizations it isn't doing (namely JIT, I think). Rust can't do the same things any faster than C can, and an early implementation of Python in Rust isn't likely to be much faster than an early implementation in C. Rust has the potential to make certain classes of optimization easier, eventually.