Rust
=====
(moderator: Kyle; notetaker: Taylor)
* Kyle: Rust code in the Git project; do we want it? Why would we want
it?
* Elijah: Anybody other than Randall that objects to it?
* Peff: I don't object, but what does it mean for existing developers?
Will non-Rust developers need to start learning?
* Emily: The avenue for introducing Rust is replacing low-level C
libraries that are complicated and un-maintainable.
* Peff: What's low-level? Peff considers strbuf to be low-level, but
Emily considers merge-ort.
* Kyle: Anything dealing with untrusted inputs would be a good spot to
start.
* Patrick: Instead: take a system like reftables that is already
self-contained.
* Jonathan: Another nice thing: if someone is on a platform without good
Rust support, then they could stll use Git without reftables.
* brian: Rust is optional, can we add small new features and performance
improvements that replace existing code, but it's not required.
* Emily: are we then carrying parallel versions of the same thing? What
does that mean for the C version?
* Taylor: I don't want to double our vulnerable surface area.
* Patrick: Right, either you go all in or don't.
* Taylor: I don't want to give too much stock to a small number of
people/platforms and hold the project hostage.
* Emily: old versions aren't going away.
* Patrick: Those could be maintenance releases.
* Do we need to support an older maint version in pure C
* Backport security fixes? Would issues be in both implementations?
* Do we want to encourage those without Rust support to maintain a
friendly fork C version
* Johannes: Transpile C to Rust?
* Elijah: Does that presume we're not using Rust libraries, or are those
transpile-targets as well.
* brian: We are going to have to use 'std', the question is what
versions of Rust are we going to support? Can't be the latest version,
since it only lives for six weeks.
* Taylor: vague idea of why we would want to use rust, but what are the
concrete benefits of moving to rust?
* brian: increased parallelization, can't write unsafe code,
incremental parsing of objects. When it fails, you get a panic
instead of a segfault.
* Patrick: clear ownership semantics, was a huge problem with the
memory leak work that they have been doing, it's not clear who owns
what at what time.
* Jonathan: 3 things; (a) user-facing benefit of memory safety, (b)
productivity benefit to ourselves to have better architecture makes
it easier to make changes, (c) would attract new contributors to
the project.
* Kyle: that's what I was going to say on (c), writing C is daunting.
* Patrick: I'm in the opposite camp, I'm scared of Rust!
* Why not move over to the gitoxide project? Probably not realistic
within the next 10 years, though Sebastian is doing great work.
* Taylor: great, what's the transition plan?
* Patrick: can't start until libification makes progress.
* Elijah: what about a low-enough level function that we can start with?
* Patrick: Still not work-able, there are too many global variables that
we need to contend with.
* Taylor: IMO better to port to rust first from an implementation that
we know, then libify in a language that has better support for
refactoring.
* Jonathan: likes what Patrick was saying about having modularization
make this easier. The other obstacle is that if we want to use any
Rust at all, we need to have a POLICY on how we use Rust.
* brian: C shared library built in Rust, or top-level build with cargo?
* Have had experience with a previous C-to-rust migration! C FFI to call
into Rust from C until everything is ported over.
* Patrick: modularization should be the first step, otherwise we're
going to have the same architecture that we have now. If we inherit it
now, it'll never get fixed.
* Mark: need Git to continue to be relevant in 10 years, making this
kind of change is part of that
* Maintainability is something we can invest in.
* Emily: governance can help corporate contributors behave better. Say
"your contributions have to meet this standard"
* Patrick: meanwhile I don't want to push away drive-by contributors
* Elijah: if someone wants to contribute a specific component in Rust,
such as a replacement builtin, they need to call C, what happens to
infrastructure such as option parsing?
* Emily: I really like the idea of starting with reftable
* Patrick: I was going to make a Rust implementation of reftable anyway
