> I am far from a Rust expert, but I think that a more modern, memory-safe > language will attract newer contributors who may have a fresher > perspective on the project, and I think that's a good thing. Aren't they likely to contribute to gitoxide? There, they get a clean slate without having to deal with the least-fun part (bidings). > It is also not the Git project's responsibility to ensure that every > platform is Rust-friendly. That's true, of course. And nobody is entitled to indefinie updates, but on the other hand, there's still some implicit contract with users. I really don't think git would have the adoption it does today if it had adopted a Rust-like language in the same state Rust is now from the start. (In exactly the same way, git doesn't gratuitously break compatibility every release either. Can it? Yes, and git can change the platforms it runs on, but it's something to be taken seriously.) > Hopefully the platforms that we currently support but won't after this > patch series have niche enough workloads that they do not need the > absolute latest-and-greatest Git release at all times. I mention this in my other email, but it's not just about ancient platforms. It's also about new ones, or ones where Rust supports them poorly despite them being relevant. > Yeah, I think that this is the most interesting part of the discussion > here. I am not knowledgeable enough about Rust's release cadence and > platform compatibility to have an opinion here. But I trust brian's > judgement ;-). It gets a new release every 6 weeks and no other releases are supported.
