Author: Stephan Sokolow
Created at: 2025-11-18 08:27
Number: 71
Clean content: I hope nobody will mind if my first post as a complete newcomer to the forum (though very far from one with Python or Rust) is letting my designed-to-win-trivia-games brain provide some context, clarifications, etc. for various things across the thread as a whole. Also, sorry for splitting this across multiple posts but, even after pessimizing all my citations to “Search for …” annotations, it was still claiming I had more than two links in it. (If this posts, then I guess it meant two reply-to-post embeds.) Pre-PEP: Rust for CPython Core Development I’m not a core dev nor expert in the internals of CPython, but I wanted to chime in to resonate with the question from @MegaIng , pointing out though that it looks to me (as a Python user) that the community in general is more “approachable” in comparison to what happened during the integration of some Rust in the Linux kernel. 
Out of curiosity, what would this mean for both PyO3 and RustPython ? Have you reached out to the mantainers of the latter for feedback on how to approach this possibilit… Finally, if I recall rust applications tend to be a bit “bloated” in binary size, although there are some tricks that can be done at compile time to reduce this - what do these tricks imply on performance I have no idea. The answer depends on how long ago you remember that from. Rust’s history has been a tale of improving defaults on this front and I don’t know where you draw the line on “bloated”. For example, prior to Rust 1.28 (Search for “Announcing Rust 1.28” site:blog.rust-lang.org ), some platforms embedded a copy of jemalloc but it now defaults to the system allocator. Rust still statically links its standard library, which is distributed as a precompiled “release + debug symbols” artifact to be shared between release and debug profiles and, for much of its life, there was no integrated support for stripping the resulting binaries. According to the Profiles (Search for “The Cargo Book” “Profiles” site:doc.rust-lang.org ) section of The Cargo Book, strip = "none" is still the default setting for the release profile. If I do a simple cargo new and then cargo build --release the resulting “Hello, World!”, the binary is 463K, which drops to 354K if the debuginfo is stripped. That remaining size includes things like a statically linked copy of libunwind which wouldn’t be needed if using abort on panic as mentioned by Emma Smith… but I’m not up to speed on how much of that will get stripped out without rebuilding the standard library to ensure it isn’t depending on them. (See my later mention of how the Rust team are currently prioritizing stabilizing -Zbuild-std as part of letting “remove kernelspace Rust’s dependency on nightly features” shape much of the 2025 roadmap.) Beyond that, one potentially relevant piece of tooling is dragonfire ( amyspark/dragonfire on the FreeDesktop Gitlab) as introduced in Linking and shrinking Rust static libraries: a tale of fire. (Search for “Linking and shrinking Rust static libraries: a tale of fire” site:centricular.com ) (Which is concerned with deduplicating the standard library when building Rust-based plugins as static libraries.) Pre-PEP: Rust for CPython Core Development Doesn’t “C“ in the name of “CPython“ means “C programming language”? If so, shouldn’t the project be eventually renamed when a significant part of it is (re)written in Rust? 
/joke, but who knows Just declare “CPython” to be referring to the stable ABI exposed rather than the implementation language. After all, the abi_stable crate for dynamically linking higher-level Rust constructs does it by marshalling through the C ABI.
