NonStop discussion around adding Rust to Git
The Linux kernel community's discussions about including Rust have gotten a lot of attention, but the kernel is not the only project wrestling with the question of whether to allow Rust. The Git project discussed the prospect in January, and then again at the Git Contributor's Summit in September. Complicating the discussion is the Git project's lack of a policy on platform support, and the fact that it does already have tools written in other languages. While the project has not committed to using or avoiding Rust, it seems like only a matter of time until maintainers will have to make a decision.
Taylor Blau opened the discussion in January by listing some of the advantages of Rust for the Git project: memory safety, lack of data races, easier refactoring (in the absence of unsafe code), and making it easier for more people to contribute to Git. "Given the allure of these benefits, I think it's at least worth considering and discussing how Rust might make its way into" Git's mainline. Blau also pointed out some questions that would need answering before the project could consider using Rust: how the language would affect platform support, which parts of Git would be easiest to migrate or extend (as is nature of sprawling mailing list discussions, the participants later touched on both), and how the change would interact with ongoing maintenance efforts.
Elijah Newren was excited about the idea, but suggested that one alternative would be to allow Rust only in optional components, in the same way that the kernel currently does. He volunteered to rewrite git-replay in Rust as a test case, noting that since (at the time of posting) it hadn't been included in a Git release, it wouldn't cause a regression. Newren was in favor of adopting Rust for different reasons than the ones Blau had listed in his message, however. He said that the Git developers often avoid making parts of the code execute in parallel, because of the difficulty of doing that correctly in C. Using Rust might allow for performance improvements from adding parallelism, and from switching to more efficient algorithms and data structures that are "quite onerous" in C. He specifically called out hash maps as a more performant alternative to the use of flat arrays in core Git code.
