I like the idea of moving CPython towards Rust, but I feel the current proposal is so conservative that it doesn’t really get us there.
The idea is to allow optional extension modules to be written in Rust. That basically means either new accelerators for modules currently written in Python, or completely new stdlib modules (which are rare). They have to be optional, which means that we must also maintain a Python (or C!) version, at least for existing modules. The concrete suggestion is base64, which is currently fully in Python.
The “optional” part means that this proposal will make the stdlib more inconsistent across users. There are many ways the stdlib is already inconsistent in this way, but I feel that’s generally a bad situation that we should avoid making worse: ideally, Python should be the same for all users, and users who use base64 shouldn’t have to think about the details of their platform to know its performance characteristics.
There might be another unfortunate consequence. Clearly, lots of people are very excited about getting Rust in CPython. But with this proposal, the only realistic way they can do that is by adding new accelerator modules. Those could be for modules that already have a C accelerator, but in that case we have to keep the C version too to avoid creating a regression for users without Rust. Or it could be for modules that are currently fully in Python. But I’m not sure how many such modules there are for which an accelerator really makes sense: in most cases, if we’d wanted a C accelerator, we’d have written one already. Therefore, we might end up with Rust code that is mostly replacing Python code, not C code, and that isn’t terribly high-impact.
To get safety wins from using Rust, we have to stop using C. Not necessarily everywhere, definitely not everywhere immediately, but at least somewhere. So for this proposal to be accepted, I feel there must be a clear path towards making it possible to replace existing C code with Rust, even if that means making Rust required.