If Rust makes its way into the Linux Kernel, another mature C project, I wouldn’t be surprised if a Rust interpreter replaces CPython.
RustPython: A Python Interpreter Written in Rust
51–60 of 75 posts
Re: RustPython: A Python Interpreter Written in Rust
#52Does this have faster startup times than cpython? Every time I want to rewrite a shell function in python, I always hesitate due to the slow startup.
How fast does it really need to be? On my M2 macbook air:
$ time A=1 B=1 python -c "import os; print(int(os.getenv('A'))+int(os.getenv('B')))"
2
real 0m0.068s
user 0m0.029s
sys 0m0.026sRe: RustPython: A Python Interpreter Written in Rust
#53Does this have faster startup times than cpython? Every time I want to rewrite a shell function in python, I always hesitate due to the slow startup.
How fast does it really need to be? On my M2 macbook air: $ time A=1 B=1 python -c "import os; print(int(os.getenv('A'))+int(os.getenv('B')))" 2 real 0m0.068s user 0m0.029s sys 0m0.026s
Eh. Once you start using imports, python slows down dramatically.
So I guess it really just depends what your scripts use.
Re: RustPython: A Python Interpreter Written in Rust
#54I don't understand how it's possible that we just randomly come across a project that just casually implements a Python interpreter in Rust. Don't these things take a massive amount of effort? Wouldn't this be making waves much earlier in its development process? I feel the same way about Ruff, for example. One day it was "black all the things" and the next it's "btw we just reimplemented the entire Python formatting…
A quick check on the contributors page shows ~8ish heavy contributors working over the course of 6 years and 13k commits. That's a good thing to check for any project you're thinking about integrating with IMO.
That said, my experience has been that adding business features in Rust apps is quite fast indeed!
Re: RustPython: A Python Interpreter Written in Rust
#55I don't understand how it's possible that we just randomly come across a project that just casually implements a Python interpreter in Rust. Don't these things take a massive amount of effort? Wouldn't this be making waves much earlier in its development process? I feel the same way about Ruff, for example. One day it was "black all the things" and the next it's "btw we just reimplemented the entire Python formatting…
For me the "uv" manager has changed my Python experience because: (1) it has a correct resolver whereas "pip" certainly doesn't and I'm not sure about poetry, (2) it is crazy fast, (3) "uv" is just a binary which I can pip into my system. (3) is important because if it was written in Javascript or Java or Python or .NET or many other languages I'd have to learn something about the runtimes of those environment to get…
(Thank you for this, it was really inspiring for me to read.)
Re: RustPython: A Python Interpreter Written in Rust
#56Earlier quoted context omitted.
For me the "uv" manager has changed my Python experience because: (1) it has a correct resolver whereas "pip" certainly doesn't and I'm not sure about poetry, (2) it is crazy fast, (3) "uv" is just a binary which I can pip into my system. (3) is important because if it was written in Javascript or Java or Python or .NET or many other languages I'd have to learn something about the runtimes of those environment to get…
I'm really looking forward to uv being a drop-in replacement for Poetry. I don't know if that's what they're planning to do, though. Does it currently have all the niceties of Poetry (dependency management, locks, building wheels, etc?).
Yeah, that's definitely within scope for what we're trying to build, and we've been hard at work on extending uv to support those workflows (platform-agnostic resolution, lockfiles, etc.). Honestly, a lot of it is already implemented, but not yet stabilized or announced. Coming soon.
Re: RustPython: A Python Interpreter Written in Rust
#57Interesting that it relies on OpenSSL, either dynamically from the OS or vendored at compile time. I wonder what the implications would be for using something like rustls. You’d get TLS batteries included and kill a large external dependency… but possibly introduce behavior changes to low-level cryptographic operations, which is scary.
Still, the maintainers stated that they don’t plan to implement Python’s readline module because they already have a rust implementation of readline. A similar argument could apply here - use native rust implementations of dependencies and expose them via the expected Python APIs. This would break some ambitious Python programs, but those probably wouldn’t consider alternative runtimes anyway.
Re: RustPython: A Python Interpreter Written in Rust
#58I wonder if this would make Python web applications more secure at interpreter and library level.
Running it on hardened Linux, OpenBSD, or FreeBSD was a start. A Rust implementation might help.
I also miss setups like eCos RTOS where a GUI determined which features got compiled in. Strip each Python app down to just what it needs in the interpreter. Might squeeze it in L1-L2 cache that way, too. Aside from embedded (eg MicroPython), has anyone anything like that for use on servers?
Re: RustPython: A Python Interpreter Written in Rust
#59Earlier quoted context omitted.
> yes, people do depend on objects being eagerly freed I get that this must be one aspect of the necessity of the GIL but I mean, C++ also has eager free behavior due to RAII and threads are working fine there, as long as you know what you're doing. Perhaps that's the rub though, it's pretty easy to crash/deadlock in C++ and we blame the programmer rather than the language.
Idiomatic C++ relies much more heavily on ownership and not so much on refcounting. If you have code that's a rat's nest of shared_ptr, it's going to perform very poorly in a multithreaded environment. But that's why any C++ guru will tell you to not make a rat's nest of shared_ptr . When refcounting is commonly used in C++, like with GUI code or dependency graphs of network requests, it's usually in non-performance-…
Right so you're saying that Python's need to keep ref counts is what leads to the need for synchronizing updates, leading to the need for a lock, more or less. Which is only needed in C++ if you program in a kind of Python style. Makes sense and is a good point.
Re: RustPython: A Python Interpreter Written in Rust
#60Earlier quoted context omitted.
> Don't these things take a massive amount of effort? Yes, RustPython has been in development since at least 2018. > Wouldn't this be making waves much earlier in its development process? It's been posted on HN several times before: https://hn.algolia.com/?q=rustpython
Ah ok, it's at least comforting to know that I missed it, rather than there are superhuman developers that crank these projects out in an afternoon.
I've had some fun converting some of my Python scripts into Rust and it's really not that difficult with the help of modern tools once you wrap your head around Rust. Python is too huge to crank out in an afternoon, for sure, but on the human level, the translation from python to something compiled is a well trod path.