From: Taylor Blau <me@ttaylorr•com>
To: git@vger•kernel.org
Subject: [TOPIC 01/11] Rust
Date: Fri, 20 Sep 2024 10:17:33 -0400 [thread overview]
Message-ID: <Zu2D/b1ZJbTlC1ml@nand.local> (raw)
In-Reply-To: <Zu2DmS30E0kKug2a@nand.local>
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
next prev parent reply other threads:[~2024-09-20 14:17 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-20 14:15 Notes from the Git Contributor's Summit, 2024 Taylor Blau
2024-09-20 14:17 ` Taylor Blau [this message]
2024-09-20 16:20 ` [TOPIC 01/11] Rust rsbecker
2024-09-23 2:25 ` Sean Allred
2024-09-23 12:17 ` rsbecker
2024-09-24 15:30 ` Phillip Wood
2024-09-24 22:44 ` rsbecker
2024-09-27 9:37 ` Sean Allred
2024-09-27 12:23 ` rsbecker
2024-09-27 17:40 ` rsbecker
2024-09-20 14:17 ` [TOPIC 02/11] Top-level lib/ directory Taylor Blau
2024-09-20 14:18 ` [TOPIC 03/11] Structured Error Handling Taylor Blau
2024-09-20 14:19 ` [TOPIC 04/11] Platform Support Policy Taylor Blau
2024-09-20 14:19 ` [TOPIC 05/11]: SHA 256 / Git 3.0 Taylor Blau
2024-09-20 19:22 ` Junio C Hamano
2024-09-20 14:20 ` [TOPIC 06/11] Git and Software Freedom Conservancy Taylor Blau
2024-09-20 14:20 ` [TOPIC 07/11] New Contributors and Discord Taylor Blau
2024-09-20 22:48 ` Junio C Hamano
2024-09-21 17:02 ` Kousik Sanagavarapu
2024-09-22 19:15 ` Junio C Hamano
2024-09-22 19:44 ` Junio C Hamano
2024-09-23 13:51 ` Konstantin Ryabitsev
2024-09-23 21:31 ` Junio C Hamano
2024-09-24 18:06 ` Konstantin Ryabitsev
2024-09-24 19:15 ` Junio C Hamano
2024-09-24 19:23 ` Konstantin Ryabitsev
2024-09-27 10:08 ` Phillip Wood
2024-09-27 19:22 ` Junio C Hamano
2024-10-01 15:23 ` Phillip Wood
2024-09-20 14:21 ` [TOPIC 08/11] Modern Build Systems Taylor Blau
2024-09-23 2:01 ` Eli Schwartz
2024-09-24 12:13 ` Patrick Steinhardt
2024-09-20 14:22 ` [TOPIC 09/11] Bundle-URI on fetch / resume-able clone Taylor Blau
2024-09-20 14:22 ` [TOPIC 10/11] Project Tracking Taylor Blau
2024-09-20 19:41 ` Junio C Hamano
2024-09-20 19:49 ` Junio C Hamano
2024-09-23 9:15 ` Phillip Wood
2024-09-20 14:23 ` [TOPIC 11/11] git-scm.com state of the site Taylor Blau
-- strict thread matches above, loose matches on Subject: below --
2024-08-24 17:20 [GSoC][PATCH] unit-tests: add tests for oidset.h Ghanshyam Thakkar
2024-08-26 7:02 ` Patrick Steinhardt
2024-08-26 9:31 ` Christian Couder
2024-08-26 15:46 ` Junio C Hamano
2024-09-26 18:28 ` Junio C Hamano
2024-09-26 19:12 ` [PATCH] howto-maintain-git: discarding inactive topics Junio C Hamano
2024-09-27 8:57 ` [GSoC][PATCH] unit-tests: add tests for oidset.h Christian Couder
2024-09-27 18:47 ` Junio C Hamano
2024-09-28 7:02 ` Patrick Steinhardt
2024-09-30 18:48 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zu2D/b1ZJbTlC1ml@nand.local \
--to=me@ttaylorr$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox