Author: Stephan Sokolow
Created at: 2025-11-18 08:28
Number: 72
Clean content: Pre-PEP: Rust for CPython Core Development I have long liked the idea of doing something like this, and as someone who always introduces memory leaks and segfaults and such any time he writes any kind of C extension code, I welcome the idea of more modern zero-cost abstractions for that [1] . 
However, one cost I think that has not been mentioned here is the effect that this could have on build times. In my experience, compile times for Rust (and C++) are much slower than for C. On my 2019 Thinkpad T480, from a fresh clone of CPython, I ca… I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? I don’t see why it needs to be slow. As laid out in The Rust compiler isn’t slow; we are. (Search for "The Rust compiler isn't slow; we are." site:blog.kodewerx.org ), rustc is already faster than compiling C++ with GCC and the reason builds are slow has more to do with how much the Rust ecosystem enjoys the creature comforts of macros and monomorphized generics. Pre-PEP: Rust for CPython Core Development In my experience incremental Rust builds are also very fast–the initial setup (including downloading and building all the dependencies) can be slow, but it’s able to do fast incremental builds just fine. 
Also, there’s a big difference between debug and release mode–building in debug mode is way faster. I would be surprised if this impacted iteration time unless you’re trying to rebuild the world every time. …and they’re working on making it faster still. Aside from “Relink, Don’t Rebuild”, as mentioned by Jubilee, there are two bottlenecks which disproportionately affect incremental rebuilds right now: First, while there’s parallelism between crates and in the LLVM backend, the rustc frontend is single-threaded. Work is in progress and testable in nightly (Search for “Faster compilation with the parallel front-end in nightly” site:blog.rust-lang.org ) for making the frontend multithreaded. They’re also working on rustc_codegen_cranelift ( rust-lang/rustc_codegen_cranelift on GitHub) which is a non-LLVM backend for rustc which makes more Go-like trade-offs for compile-time vs. runtime performance and is intended to eventually become the default for the debug profile. Second, linking. They’ve been rolling out LLD as a faster default linker on a platform-by-platform basis and it came to Linux in 1.90. (Search for “Announcing Rust 1.90.0” site:blog.rust-lang.org ) Beyond that, mold is faster still (it’s what I use on my system) and wild ( davidlattimore/wild on GitHub), yet faster, is being developed with an eye toward becoming default for debug builds alongside rustc_codegen_cranelift. (i.e. Doesn’t cover all the needs of a fully general-purpose linker, but does make debug builds for the majority of them very quick.)
