Now this is something I will donate money to…
Python with Rust as its foundation sounds like the best idea ever.
I’m curious to know whether or not it would be possible (or reasonable) to eventually get the same or better performance as CPython.
Python with Rust as its foundation sounds like the best idea ever.
I’m curious to know whether or not it would be possible (or reasonable) to eventually get the same or better performance as CPython.
I think a RustPython implementation would be pretty cool. You could definitely take that opportunity to worry about performance more than CPython does while also worrying about interoperability more than PyPy does.
Or I'm missing your point and you're suggesting a drop-in replacement for CPython that supports all the same C-based libraries as CPython does.
No, that was my point basically, although I could imagine something like this shipping with some basic libraries and package support, and then having a similar ecosystem to the current python ecosystem.
I think not having support for C modules would hamper long term adoption. I would absolutely love to adopt this for my stuff, but off the top of my head- I use uvloop and confluent-Kafka, both of which are largely written in in C. Moving away from those would be hard-ish.
Literally all of them, without any issues? I'm working on implementing support for Ruby's C extensions in an alternative implementation and it's a right slog.
I have a Django app that does some heavy data serialization and I'm not yet ready to optimize those serializers in another language.
I can't wait to try this out.
Crumb. I didn't realise pypy is on 3.5.3. Loves me my f strings.
The data structures are slow by design.
The way we use these data structures is quite inefficient.
Having a fast interpreter only about doubles the execution speed in most programs leaving another factor of 50 open for future generations.
Ints and classes can be slow though.
Anything I don't know ?
Of course if you compare to static languages it's slow. Of course you can write low level specialized DS. Duh.
Why do you think it's the "best idea ever"? What are the benefits over any other Python implementation?
Full security for Python apps would require consideration of each layer of abstraction:
1. User's code in Python.
2. The interpreter and extensions.
3. How these interact.
4. If added for performance or security, any assembly code plus its interactions.
Rewriting Python interpreter in Rust mainly addresses No 2. An example of a method to address all of them would be Abstract, State Machines which can represent simultaneously language semantics, software, and hardware. Tools like Asmeta exist to make them like programming languages. The verification would probably be manual, specialist work. Whereas, Rust's compiler gives you key properties with just annotations for many and working with borrow-checker for a few.
Has this actually been a problem, though? I'm no lover of python, but tons of people seem to use, for example, Django, without incident.
Rust will allow to safely invite a broader range of contributors, because there are so many things you don't need to check. This also means a smaller number of required tests, and because Rust uses higher level constructs that C, more productivity in general.
So basically, on the long run, more people, able to do more things.
Besides, on of the goals of the main implementation is to stay simple, which is hard to do in C. For those reasons, and because of the potential for unreliability and security, CPython is quite slow.
We can't optimize it, because it would make it too complex.
But with a rust implementation, one can hope to suddenly be able to apply more optimizations.
It's all theorical of course, but it's a nice hope.
Or two and a half decades of performance neglect.
I've read about things like dicts, sort and the like getting faster implementations, but I've never seen a big effort to make CPython faster in general. In fact the first versions of 3.x were even allowed to regress to slower than 2.x.
> [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.
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].
Rust makes it easier to write programs that don't leak memory and don't have data races, but it doesn't make them run faster.
Rust also allows you to make architectural decisions in the name of performance that would be completely unmaintainable in C. See: the Servo project.
https://github.com/rust-lang/rust/issues/54878
This is not the first time it has been disabled due to an LLVM bug.
C vs. Rust: 6 wins for C, one draw, 3 wins for Rust
C++ vs. Rust: 5 wins for C++, two draws, 3 wins for Rust
The wins one way or another are also not by particularly large margins.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
This may go on to shift marginally in Rust's favor once a soundness bug related to non-aliasing of references is fixed in LLVM and the compiler can safely leverage some guarantees that Rust provides that C and C++ cannot.
Also others have noted that speed was not a primary focus of CPython