On Wed, Jan 10, 2024 at 3:19 PM Taylor Blau <me@xxxxxxxxxxxx> wrote: > > Over the holiday break at the end of last year I spent some time > thinking on what it would take to introduce Rust into the Git project. > > There is significant work underway to introduce Rust into the Linux > kernel (see [1], [2]). Among their stated goals, I think there are a few > which could be potentially relevant to the Git project: > > - Lower risk of memory safety bugs, data races, memory leaks, etc. > thanks to the language's safety guarantees. > > - Easier to gain confidence when refactoring or introducing new code > in Rust (assuming little to no use of the language's `unsafe` > feature). > > - Contributing to Git becomes easier and accessible to a broader group > of programmers by relying on a more modern language. > > Given the allure of these benefits, I think it's at least worth > considering and discussing how Rust might make its way into Junio's > tree. > > I imagine that the transition state would involve some parts of the > project being built in C and calling into Rust code via FFI (and perhaps > vice-versa, with Rust code calling back into the existing C codebase). > Luckily for us, Rust's FFI provides a zero-cost abstraction [3], meaning > there is no performance impact when calling code from one language in > the other. > > Some open questions from me, at least to get the discussion going are: > > 1. Platform support. The Rust compiler (rustc) does not enjoy the same > widespread availability that C compilers do. For instance, I > suspect that NonStop, AIX, Solaris, among others may not be > supported. > > One possible alternative is to have those platforms use a Rust > front-end for a compiler that they do support. The gccrs [4] > project would allow us to compile Rust anywhere where GCC is > available. The rustc_codegen_gcc [5] project uses GCC's libgccjit > API to target GCC from rustc itself. > > 2. Migration. What parts of Git are easiest to convert to Rust? My > hunch is that the answer is any stand-alone libraries, like > strbuf.h. I'm not sure how we should identify these, though, and in > what order we would want to move them over. > > 3. Interaction with the lib-ification effort. There is lots of work > going on in an effort to lib-ify much of the Git codebase done by > Google. I'm not sure how this would interact with that effort, but > we should make sure that one isn't a blocker for the other. > > I'm curious to hear what others think about this. I think that this > would be an exciting and worthwhile direction for the project. Let's > see! > > Thanks, > Taylor > > [1]: https://rust-for-linux.com/ > [2]: https://lore.kernel.org/rust-for-linux/20210414184604.23473-1-ojeda@xxxxxxxxxx/ > [3]: https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html#c-talking-to-rust > [4]: https://github.com/Rust-GCC/gccrs > [5]: https://github.com/rust-lang/rustc_codegen_gcc > Two good reference codebases out there: Abstractions over libgit2 Repo: https://github.com/rust-lang/git2-rs Docs: https://docs.rs/git2/latest/git2/ gix, a WIP reimplementation of git. This is far from complete but does a lot of threading / async to apparently get quite fast. Repo: https://github.com/Byron/gitoxide Docs: https://docs.rs/gix/latest/gix/ If the git project does decide to go forward with this, there is probably a lot of completed work that can be pulled from either of those sources.
