Hi Dragan, On Wed, Jan 17, 2024 at 1:30 PM Dragan Simic <dsimic@xxxxxxxxxxx> wrote: > > On 2024-01-11 17:57, Elijah Newren wrote: > > Hi Dragan, > > I apologize for my delayed response. No worries; I'm often hit or miss on my responses these days as well. > > On Wed, Jan 10, 2024 at 9:39 PM Dragan Simic <dsimic@xxxxxxxxxxx> > > wrote: > >> > >> On 2024-01-11 01:33, Elijah Newren wrote: > >> > On Wed, Jan 10, 2024 at 1:57 PM Dragan Simic <dsimic@xxxxxxxxxxx> > >> > wrote: > >> >> > >> >> 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! > > > 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.
