[TOPIC 01/11] Rust

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