[NOTES 04/11] Rust
From: Taylor Blau <hidden>
Date: 2025-10-06 19:19:01
Topic: Rust Leader: Patrick Steinhardt 13:05am-13:30pm PT * Recurring topic from past years, but sparked again by Ezekiel's contributions on xdiff * We're favorable towards it, but we haven't previously agreed on a timeline * Platforms that don't have Rust support: NonStop, Alpha, Cygwin, and some others brought up by Gentoo * Patrick has a series up to let us provide notification to users that Git will start depending on Rust * Led to lots of discussion both on the mailing list and outside, which had the good effect of making more people aware of the upcoming change * Ezekiel is trying to pass some of the blame to a big brother – he's happy to take it ;-) * Ezekiel is more interested in the technical details than the policy details, though we need the policy details figured out * Having Rust be optional leads to code being written twice and increasing the maintenance support; having mandatory Rust support is needed to avoid that * brian wrote sha256 interop code in Rust * Would be nice to hand over maintenance for some kind of (Rust-optional) LTS release to someone else in the community * We have lots of global state that we need to get rid of, and lots of other cleanup * Long term goal may be to eventually replace all of C, though it's not clear if we should take that whole goal or just start with pieces that make sense. Also, we've got a learning process ahead of us, so our goalposts may need to change as we learn. * Rust might be helpful for libification reasons, but tying libification to an already big change might make it too big * Rust rewrite could mean implementing new subcommands (as discussed earlier) in Rust instead of rewriting bug-for-bug existing code * There are lots of updating that can be done before switching to Rust, e.g. switching to unambiguous types * Rust can be used to replace things at an individual function level * Just rewriting in Rust doesn't turn the existing system into nice abstraction boundaries or reusable modules. We have existing efforts to try to clean those up in various ways, e.g. the pluggable object store work. * Rust makes unit tests much easier and ergonomic, and starting by writing tests of existing C code makes a lot of sense as a way to begin a migration. * Large organizations and governments are going to start pushing for people to move away from C for security reasons. * Major reason(s) to adopt Rust * Threading * Error propagation * Difficult to know who owns what in C - Rust improves maintainability * Attracting more contributors (it's the most popular according to StackOverflow)