Author: Neil Schemenauer
Created at: 2025-11-20 23:37
Number: 188
Clean content: I feel the current proposal is so conservative that it doesn’t really get us there. I think that’s okay.  This is going to be a many-year, perhaps on the order of decades, project.  The first step is to add Rust as an optional feature of the CPython build.  That will allow us to solve some tricky problems about how we can make Rust and C co-exist.  And, we can find out how many platforms are going to be affected by this (e.g. they can’t get the optional features to build) and fix that for as many platforms as we can. This initial step doesn’t necessarily help with code safety, API cleanliness, or performance aspects.  I’m sure others will disagree but, to me, the benefits that Rust can bring on those is clearly demonstrated in other projects.  We don’t need to prove those specifically for CPython. Edit: maybe it’s useful to enumerate what I think are the clear benefits that Rust could bring.  I’m not a Rust programmer so knowledgeable people will need to correct me if I’m wrong (as I’m sure they will gleefully do). array bounds checking: in the year 2025, it’s crazy we are using a programming language that doesn’t do this.  Yes, there can be extra overhead.  No, you are not smart enough to get it correct. use-after-free and other memory lifetime bugs.  Rust’s borrow checker avoids most of these at compile time. integer overflow: Rust doesn’t prevent it but at least it defines what happens.  Undefined behavior is bad. scope based cleanup: I’ve heard that the C language standard might eventually be getting something like __attribute__((cleanup(...))) .  It’s probably going to be decades before CPython could actually rely on C compilers supporting that.  This pattern comes up so often and it’s painful we don’t have a built-in language feature that supports it. There are other benefits and conveniences but these are the big ones, IMHO.
