On 2024-01-10 21:16, Taylor Blau 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.
Quite frankly, that would only complicate things and cause
fragmentation. The goal of introducing Rust into the Linux kernel is
to, possibly, have some new "leafs" written in Rust, such as some new
device drivers. No existing kernel code, AFAIK, has been planned to be
rewritten in Rust.
Thus, Git should probably follow the same approach of not converting the
already existing code, but frankly, I don't see what would actually be
the "new leafs" written in Rust.
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
