7 ms·

I'm not sure if it's an insecurity thing or an immaturity thing, but when all these stories pop up, I always wonder why rust enthusiasts don't just prove their

I'm not sure if it's an insecurity thing or an immaturity thing, but when all these stories pop up, I always wonder why rust enthusiasts don't just prove their point by making their own "modern" and non-"retro" tech. If you can make something better, just do it already, and people will switch to it when they see the benefits. This parasitic "you must accept rust in your long-standing project" model is so off-putting, as is always evident by the complaints it causes. I love projects like Redox that try to do their own thing... why doesn't the rust community rally around projects like that and turn them into cve-free masterpieces that people will want to use?

jeffparsons 11mo ago
This email is from a Debian maintainer, about Debian introducing a new hard dependency on Rust. It's not some random Rust advocate telling Debian folks that they should use Rust against their will. Yes there are absolutely some obnoxious "you should rewrite this in Rust" folks out there, but this is not a case of that.
- richard_todd 11mo ago
  There are like 1000 Debian maintainers, right? This person doesn't speak for the project as a whole, and as far as I can tell he is telling Debian folks they will be accepting rust whether they want it or not, and whether their preferred architecture is supported or not. Maybe there was some organizational vote on this, but if so it isn't referenced in the thread. It says "I plan", not "Debian decided to". And regardless, my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.
  - pornel 11mo ago
    You seem to think of "rust enthusiasts" as some organized group with a goal of writing Rust for the sake of it. Rust is long past such extremely early adopter phase. What you're seeing now is developers who are interested in writing a better version of whatever they're already working on, and they're choosing Rust to do it. It's not a group "Rust enthusiasts" ninjas infiltrating projects. It's more and more developers everywhere adopting Rust as a tool to get their job done, not to play language wars.
    - richard_todd 11mo ago
      Nah, I called out redox and another commenter pointed out ripgrep as an even better example of what I’d prefer to see, and those are also by what I would call rust enthusiasts. I don’t think of them as a monolithic group. Where we disagree is I would not call injecting rust into an established project “writing a better version”. I would love it if they did write a better version, so we could witness its advantages before switching to it.
      - dralley 11mo ago
        They are referring to adopting the Sequoia PGP library, which is written in Rust. There are plenty of benefits to using Sequoia which you can investigate now, no need to theoretically wait for the integration to happen. Not coincidentally, the RPM package manager also adopted Sequoia PGP.
        richard_todd 11mo ago
        First off, the mail references far more rust adoption than just Sequoia, but since you bring it up: here is how RPM adopted Sequoia in Fedora-land. There was a proposal, a discussion with developers about the ramifications (including discussion about making sure the RPMs built on all architectures), and there were votes and approvals. Costs and benefits and alternatives were analyzed. Here's a page that has links to the various votes and discussion: https://fedoraproject.org/wiki/Changes/RpmSequoia https://fedoraproject.org/wiki/Changes/RpmSequoia Can't you see how much more thought and care went into this, than is on display in this Debian email (the "if your architecture is not supported in 6 months then your port is dead" email)?
  - throwaway7356 11mo ago
    > my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever. That's not how open source software development works. I wasn't asked by Linus whether ipchains should become the default over ipfirewall nor whether iptables should become over ipchains. I wasn't asked whether GCC should use C++ instead of C as the language to build GCC itself. I can go on with lots of examples. Why should APT be different and require the maintainers to fork their own project do introduce changes? Why should an undefined "community" (who is that? apparently not the APT developers...) decide? Does this have to be done for every code change in APT?
    - richard_todd 11mo ago
      ipchains is a perfect representation of what I want to see. They introduced it as an option alongside ipfirewall in 2.1, made it the default but allowed fallback to ipfirewall in 2.2, and removed ipfirewall in 2.4. That is a sane way to introduce a large breaking change. Not to mention they provided compatibility scripts to try to smooth over the user-side differences. They certainly did NOT say "I'm replacing ipfirewall with ipchains in six months, and if your distro can't handle it you should sunset your distro." It shouldn't be controversial to request a measured approach when making major changes to software lots of people depend on. That's part of the burden of working on important software. Note I'm not against apt or anything moving to rust. edit: spelling
      - throwaway7356 11mo ago
        Ah, so the same that seems to be happening here? As https://lists.debian.org/debian-devel/2025/10/msg00288.html https://lists.debian.org/debian-devel/2025/10/msg00288.html says Rust is already a requirement on all but four architectures: > Rust is already a hard requirement on all Debian release architectures and ports except for alpha, hppa, m68k, and sh4 (which do not provide sqv). And just like with the kernel the fallback gets removed eventually.
Seattle3503 11mo ago
Thats exactly what happed with ripgrep. People seem to like it.
- richard_todd 11mo ago
  Exactly! People love ripgrep because of its clear advantages, and had the developers been interested in making posix mode for it, I'm certain at least some distros would have made it the default by now.
zamalek 11mo ago
This was done with uutils. I'm daily driving them.

jeffparsons 11mo ago

This email is from a Debian maintainer, about Debian introducing a new hard dependency on Rust. It's not some random Rust advocate telling Debian folks that they should use Rust against their will. Yes there are absolutely some obnoxious "you should rewrite this in Rust" folks out there, but this is not a case of that.

richard_todd 11mo ago
There are like 1000 Debian maintainers, right? This person doesn't speak for the project as a whole, and as far as I can tell he is telling Debian folks they will be accepting rust whether they want it or not, and whether their preferred architecture is supported or not. Maybe there was some organizational vote on this, but if so it isn't referenced in the thread. It says "I plan", not "Debian decided to". And regardless, my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.
- pornel 11mo ago
  You seem to think of "rust enthusiasts" as some organized group with a goal of writing Rust for the sake of it. Rust is long past such extremely early adopter phase. What you're seeing now is developers who are interested in writing a better version of whatever they're already working on, and they're choosing Rust to do it. It's not a group "Rust enthusiasts" ninjas infiltrating projects. It's more and more developers everywhere adopting Rust as a tool to get their job done, not to play language wars.
  - richard_todd 11mo ago
    Nah, I called out redox and another commenter pointed out ripgrep as an even better example of what I’d prefer to see, and those are also by what I would call rust enthusiasts. I don’t think of them as a monolithic group. Where we disagree is I would not call injecting rust into an established project “writing a better version”. I would love it if they did write a better version, so we could witness its advantages before switching to it.
    - dralley 11mo ago
      They are referring to adopting the Sequoia PGP library, which is written in Rust. There are plenty of benefits to using Sequoia which you can investigate now, no need to theoretically wait for the integration to happen. Not coincidentally, the RPM package manager also adopted Sequoia PGP.
      - richard_todd 11mo ago
        First off, the mail references far more rust adoption than just Sequoia, but since you bring it up: here is how RPM adopted Sequoia in Fedora-land. There was a proposal, a discussion with developers about the ramifications (including discussion about making sure the RPMs built on all architectures), and there were votes and approvals. Costs and benefits and alternatives were analyzed. Here's a page that has links to the various votes and discussion: https://fedoraproject.org/wiki/Changes/RpmSequoia https://fedoraproject.org/wiki/Changes/RpmSequoia Can't you see how much more thought and care went into this, than is on display in this Debian email (the "if your architecture is not supported in 6 months then your port is dead" email)?
- throwaway7356 11mo ago
  > my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever. That's not how open source software development works. I wasn't asked by Linus whether ipchains should become the default over ipfirewall nor whether iptables should become over ipchains. I wasn't asked whether GCC should use C++ instead of C as the language to build GCC itself. I can go on with lots of examples. Why should APT be different and require the maintainers to fork their own project do introduce changes? Why should an undefined "community" (who is that? apparently not the APT developers...) decide? Does this have to be done for every code change in APT?
  - richard_todd 11mo ago
    ipchains is a perfect representation of what I want to see. They introduced it as an option alongside ipfirewall in 2.1, made it the default but allowed fallback to ipfirewall in 2.2, and removed ipfirewall in 2.4. That is a sane way to introduce a large breaking change. Not to mention they provided compatibility scripts to try to smooth over the user-side differences. They certainly did NOT say "I'm replacing ipfirewall with ipchains in six months, and if your distro can't handle it you should sunset your distro." It shouldn't be controversial to request a measured approach when making major changes to software lots of people depend on. That's part of the burden of working on important software. Note I'm not against apt or anything moving to rust. edit: spelling
    - throwaway7356 11mo ago
      Ah, so the same that seems to be happening here? As https://lists.debian.org/debian-devel/2025/10/msg00288.html https://lists.debian.org/debian-devel/2025/10/msg00288.html says Rust is already a requirement on all but four architectures: > Rust is already a hard requirement on all Debian release architectures and ports except for alpha, hppa, m68k, and sh4 (which do not provide sqv). And just like with the kernel the fallback gets removed eventually.

Seattle3503 11mo ago

Thats exactly what happed with ripgrep. People seem to like it.

richard_todd 11mo ago
Exactly! People love ripgrep because of its clear advantages, and had the developers been interested in making posix mode for it, I'm certain at least some distros would have made it the default by now.

zamalek 11mo ago

This was done with uutils. I'm daily driving them.