Re: [PATCH v2 00/17] RFC: Accelerate xdiff and begin its rustification

[Junio C Hamano <gitster@pobox.com>]

"Ezekiel Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

>  * Code style: Should we adopt a Rust code style of some sort? Perhaps have
>    the code always be formatted by rustfmt in its default configuration?

Sounds sensible.  I'll let folks with more Rust inclination to
figure out what _the_ style should be, but having _a_ style we all
stick to is good.

>  * Rust version: We are not using the same Rust version on all platforms in
>    CI; 32-bit builds and Windows builds require a newer Rust version to
>    successfully build.

As long as we do not have to bend backwards on the code with "if
using version X or older, use this alternative codepath" all over
the place, "pick a version that works on each platform" that results
in "due to the quality of ports, some platform's older port is
unusable and newer version is required" is not too bad, especially
for a system that is still rapidly getting improved and a bit on the
unstable side, I think.

>  * Performance with whitepsace flags: I originally intended to leave out the
>    whitespace handling because I knew it was slower,...

If the Rust guinea pig were different from how each line is hashed
in xdiff, which is targetted by am/xdiff-hash-tweak topic, then we
can leave out the whitespace-ignoring hashing from this topic
altogether.

Quite honestly, I do not like throwing away the other optimization
efforts that can be reviewed and integrated trivially, but it is
practically impossible to do so while still have a "let's start
playing with Rust" topic that targets exactly the same area.  Yes,
this topic licked the same corner of the cake first, but still,
I was hoping that the second iteration of this series would use a
different code paths as a Rust guinea pig.

After all, the primary objective of our first Rust topic is to set
the framework right (like the platform and version support policies,
how foreign interfaces like type systems get impedance-matched, what
the impact to our build infrature looks like, etc.).  It would be a
huge plus if it can at the same time demonstrate how much safer code
we can write with less effort if we switched writing some (and
gradually larger, posibly) parts in the language.

The result this cover letter has in its title, 'accelerate xdiff',
is not primarily due to use of Rust, is it?  As the other topic
demonstrates, it is to use an implementation of a faster hash
function (we can consider it to be an impressive technology
demonstration that a rust reimplementation of original C code can be
done in a very performant way).  And nobody is expecting that we
would be using Rust for speed anyway, no?