Author: Paul Ganssle
Created at: 2025-11-17 19:41
Number: 16
Clean content: 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 can build the whole thing in 2m50s (with make -j , and admittedly it taxes the machine): real	2m50.573s
user	14m57.260s
sys	0m42.975s After the initial build, incremental builds are in seconds. Not sure I know of any projects of comparable size and complexity to compare with, does anyone know if (in the extreme — I know this isn’t the plan) we were to re-write CPython in Rust, how the build times would compare? I really think that the fast iteration time and low overhead from the builds is a great feature of our current build system that I would really hate to give up. 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? My thinking is that if build times were 2x slower that would be acceptable if it meant a significant reduction in security critical bugs, but I personally wouldn’t love it if it were much slower than that. On rereading, I realized that this makes it sound like I want zero-cost abstractions to help me introduce more segfaults. If it’s unclear to anyone, I meant “to avoid that”. I have left the original wording because I like to at least initially convey that I am Chaotic Neutral. ↩︎
