Hi Dragan,

On Wed, Jan 17, 2024 at 1:30 PM Dragan Simic [off-list ref] wrote:

On 2024-01-11 17:57, Elijah Newren wrote:

quoted

Hi Dragan,

I apologize for my delayed response.

No worries; I'm often hit or miss on my responses these days as well.

quoted

On Wed, Jan 10, 2024 at 9:39 PM Dragan Simic [off-list ref]
wrote:

quoted

On 2024-01-11 01:33, Elijah Newren wrote:

quoted

On Wed, Jan 10, 2024 at 1:57 PM Dragan Simic [off-list ref]
wrote:

quoted

Thus, Git should probably follow the same approach of not converting
the
already existing code

I disagree with this.  I saw significant performance improvements
through converting some existing Git code to Rust.  Granted, it was
only a small amount of code, but the performance benefits I saw
suggested we'd see more by also doing similar conversions elsewhere.
(Note that I kept the old C code and then conditionally compiled
either Rust or C versions of what I was converting.)

Well, it's also possible that improving the old C code could also
result
in some performance improvements.  Thus, quite frankly, I don't see
that
as a valid argument to rewrite some existing C code in Rust.

Yes, and I've made many performance improvements in the C code in git.
Sometimes I make some of the code 5% or 20% faster.  Sometimes 1-3
orders of magnitude faster.  Once over 60 orders of magnitude
faster.[1]  Look around in git's history; I've done a fair amount of
performance stuff.

Thank you very much for your work!

quoted

And I'm specifically arguing that I feel limited in some of the
performance work that can be done by remaining in C.  Part of my
reason for interest in Rust is exactly because I think it can help us
improve performance in ways that are far more difficult to achieve in
C.  And this isn't just guesswork, I've done some trials with it.
Further, I even took the time to document some of these reasons
elsewhere in this thread[2].  Arguing that some performance
improvements can be done in C is thus entirely missing the point.

If you want to dismiss the performance angle of argument for Rust, you
should take the time to address the actual reasons raised for why it
could make it easier to improve performance relative to continuing in
C.

Also, as a heads up since you seem to be relatively new to the list:
your position will probably carry more weight with others if you take
the time to understand, acknowledge, and/or address counterpoints of
the other party.  It is certainly fine to simply express some concerns
without doing so (Randall and Patrick did a good job of this in this
thread), but when you simply assert that the benefits others point out
simply don't exist (e.g. your "Quite frankly, that would _only_
complicate things and cause fragmentation." (emphasis added) from your
first email in this thread[3], and which this latest email of yours
somewhat looks like as well), others may well start applying a
discount to any positions you state.  Granted, it's totally up to you,
but I'm just giving a hint about how I think you might be able to be
more persuasive.

I totally agree with your suggestions, and I'm thankful for the time it
took you to write it all down.  I'll take your advice

Great!

and refrain myself
from expressing my opinions in this thread.

...but that's not what my advice was.  My advice was that you'd be
more persuasive if you expressed your opinions differently.  Some
possible examples:

  * Stating that you are worried about the codebase becoming more
complicated or more fragmented (without dismissing the points Taylor
raised)
  * Arguing that you believe various points others raised aren't as
much of an advantage as they perceive, or even potentially aren't even
an advantage at all, not by mere assertion but by providing additional
details on the topic (statistics, anecdotes, war stories,
counter-examples, old commit messages, etc.) that back up your point
  * Stating that you don't understand why others think that advantages
they state are as significant as they pose and ask for clarification.

I think there's potentially some good points behind your positions,
and I don't want to discourage them.  I want to encourage lively,
friendly debate so that we can have the best information possible when
decisions are made.