Author: Emma Smith
Created at: 2025-11-18 00:53
Number: 50
Clean content: Donghee Na: We have a lot of low level and very optimized C code that Rust cannot express safely. A good example is the computed goto dispatch in the interpreter, which would require a large amount of unsafe code or inline assembly if we tried to reproduce it in Rust. I think this is actually a great example where Rust could be a huge improvement over C. There is  interest in the Rust community to implement a safe state machine loop, e.g. this proposal RFC: Improved State Machine Codegen by folkertdev · Pull Request #3720 · rust-lang/rfcs · GitHub . That proposal may not get into Rust, but given the interest I am sure there will be some safe solution implemented eventually. And I would like to re-iterate another point: we absolutely should not re-write things that don’t make sense to. The core interpreter loop itself may not make sense to for a while, but that doesn’t mean other important runtime things can’t be Rust, like thread state management, the parser, and others. Barry Warsaw: I would go further and predict that this will never happen, and claim that it shouldn’t be a goal of the Rust-in-Python project. Well then you’ll be really glad with this blurb I was writing in response to Donghee’s post . Speaking for myself here: The goal of this project should not specifically be to re-write CPython in Rust, but rather iteratively move more C code to Rust over time and reap the benefits for those portions of code. This may end up meaning Python becomes entirely Rust! But I don’t think that will necessarily be the end goal. Barry Warsaw: One of the soft consequences I’m especially interested in is whether this attracts more or fewer core developers contributing to the Rust bits than the C bits. I’m also quite interested in this! Given that we have seen people shifting to Rust for new 3rd-party extension modules I really hope that will translate into more contributors.
