[NOTES 04/11] Rust

[Taylor Blau <me@ttaylorr.com>]

Topic: Rust
Leader: Patrick Steinhardt
13:05am-13:30pm PT


* Recurring topic from past years, but sparked again by Ezekiel's contributions
	on xdiff
* We're favorable towards it, but we haven't previously agreed on a timeline
* Platforms that don't have Rust support: NonStop, Alpha, Cygwin, and some
	others brought up by Gentoo
* Patrick has a series up to let us provide notification to users that Git will
	start depending on Rust
* Led to lots of discussion both on the mailing list and outside, which had the
	good effect of making more people aware of the upcoming change
* Ezekiel is trying to pass some of the blame to a big brother – he's happy to
	take it ;-)
* Ezekiel is more interested in the technical details than the policy details,
	though we need the policy details figured out
* Having Rust be optional leads to code being written twice and increasing the
	maintenance support; having mandatory Rust support is needed to avoid that
* brian wrote sha256 interop code in Rust
* Would be nice to hand over maintenance for some kind of (Rust-optional) LTS
	release to someone else in the community
* We have lots of global state that we need to get rid of, and lots of other
	cleanup
* Long term goal may be to eventually replace all of C, though it's not clear if
	we should take that whole goal or just start with pieces that make sense.
	Also, we've got a learning process ahead of us, so our goalposts may need to
	change as we learn.
* Rust might be helpful for libification reasons, but tying libification to an
	already big change might make it too big
* Rust rewrite could mean implementing new subcommands (as discussed earlier) in
	Rust instead of rewriting bug-for-bug existing code
* There are lots of updating that can be done before switching to Rust, e.g.
	switching to unambiguous types
* Rust can be used to replace things at an individual function level
* Just rewriting in Rust doesn't turn the existing system into nice abstraction
	boundaries or reusable modules.  We have existing efforts to try to clean
	those up in various ways, e.g. the pluggable object store work.
* Rust makes unit tests much easier and ergonomic, and starting by writing tests
	of existing C code makes a lot of sense as a way to begin a migration.
* Large organizations and governments are going to start pushing for people to
	move away from C for security reasons.
* Major reason(s) to adopt Rust
	 * Threading
	 * Error propagation
	 * Difficult to know who owns what in C - Rust improves maintainability
	 * Attracting more contributors (it's the most popular according to
		 StackOverflow)