Git: Introduce Rust and announce it will become mandatory in the build system

[dead]

> I understand that it's a minor change in its current state. However, it is a fact that the long term goal is to port everything to rust. Once that goal is accomplished, rust will be required. So it is not at all a gross exaggeration. It's a prediction of the future.

Whose goal is this? I know that there's a perception of there being a loud, vocal contingent of people who have this goal in general, but is there anyone who actually is involved in git maintenance who has stated this intent? The proposal linked above states the following:

> As said, the entire goal is for us to have an easy playground that we can experiment on and develop the infrastructure incrementally without yet having to commit to anything.

> I'm mostly splitting out the topic of introducing Rust from the larger series that introduce it into xdiff so that we can focus more on the actual process of introducing Rust into Git and less on the potential features that we want to build on top of it.

My reading of this is that there are specific features that they at least want to consider using Rust for, and that having support for it in the build process is a prerequisite for that. That doesn't imply at all to me that they would want to rewrite all existing features in it, or to prevent new C code from being written for git after some point in the future. Even if there are some people involved with that goal, it hardly seems like that goal is shared by everyone who might be involved in that type of decision, and I'd argue that people wouldn't even have to be in agreement about that goal to be in favor of this step. I don't find it that hard to believe someone might want to allow using Rust for new features but generally be against the idea of rewriting all features in Rust.

Having written Rust professionally for six years and used it for around a decade, my experience is that there are surprisingly few prolific Rust programmers who seem to devote much time to thinking about trying to get existing projects to rewrite all of their codebase into Rust. It's much more likely that they'd just start an entirely new project that overlaps substantially with an existing one, although even then it's rare for the new project to ever get anywhere close to fully replacing the existing one (if that's even the goal); ripgrep might have wide adoption alongside grep, but grep isn't going anywhere, and I suspect that burntsushi would be one of the last people to suggest it would.

There's also a lot of significant work spent on improving Rust's ability to interoperate with other languages. Libraries made with bindgen (and cbindgen in the other direction) probably have done far more to ameliorate Rust programmers to using existing libraries in other languages than to expedite them being rewritten, and there are some popular wrappers that try to go beyond that and try to provide even more idiomatic wrappers for specific languages like pyo3 for Python, neon for NodeJS, and cxx for C++ (which was written by the same person who basically single-handedly created the current proc macro ecosystem in Rust alongside specific libraries utilizing it like serde and thiserror, so hardly someone who would have no motivation to try to have more code rewritten in Rust). If there are people making an effort being made to try to tell everyone to rewrite everything in Rust, there's just as much effort going on from people writing Rust to actively try to work with existing code in other languages, and their work is having far more impact than the first group.

I honestly can't help but wonder if the only reason the debate about rewriting stuff in Rust is still going on is that the people against it engage with it rather than just ignoring it as empty bluster. My hot take is that there's never been anywhere close to the critical mass of people with the skill and desire to put in the work that would be required to make it happen, and there likely never will be, so the debate been sustained on one side by a range from armchair quarterbacking to intentional ragebait, and on the other side by a range from misguided attempts to engage seriously with what's essentially always been just a meme to pearl-clutching at the idea that someone would dare question the status quo. Maybe there was an interesting philosophical debate to be had about the hypothetical merits of rewriting the world in Rust in the early days, but we're long past the point where there's anything useful left to say on the topic, so we'd all be better off by just collectively moving on and figuring out how things will play out in the real world. C and C++ are definitely not going anywhere in our lifetimes, and Rust has sufficiently proved that it can be used successfully in professional contexts, so the remaining questions are all going to be about tradeoffs between legitimate choices rather than jockeying to see who sticks around in a "winner-takes-all" ecosystem.

I would safely bet that the pool of C developers willing to work on a C Git going forward is much closer to exhaustion than the pool of Rust developers willing to work on a Rust(-ish) Git.

Okay then how about another interpretation: I'm a software engineer questioning the boarder group of SWEs on what they're trying. (Somehow I have to show you another interpretation I can't believe how tunneled people can be).

Also bureaucracy is added friction, usually done by humans. It can be found everywhere where you're working with humans, from leetcode interviews and code styles and practices. It's not just a bunch of signed papers.

Sure you can add the second language if adds value, but let's not pretend that the added friction isn't there. If you could solve your problems without the friction of second language it would be better.

I distinctly remember reading the comments in the thread here about the initial release of ripgrep, and I remember coming away with a strong impression not just of your technical skill (which was apparent even before reading the thread), but just how pragmatic your viewpoint was. I didn't get the feeling you had any desire to displace anything, but just to solve a specific problem for people who wanted it, and if some people preferred not to use it, that was fine too! As someone who was fairly early on in my software career then, it was an extremely valuable lesson in humility from someone with a pedigree that I presumably wouldn't ever match.

Your reappearance here after my mention is probably another useful lesson for me to have a bit more empathy for those who are reacting more strongly to this announcement than I'd otherwise understand.