6 ms·

Replacing battle tested software with untested rewrite is always a bad idea even if the rewrite is written a trendy language, key word being untested. I’m stil

Replacing battle tested software with untested rewrite is always a bad idea even if the rewrite is written a trendy language, key word being untested. I’m still shocked by the number of people who seem to believe that the borrow checker is some kind of magic. I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler.

orangeboats 1y ago
> I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. Some checks are pretty much impossible to do statically for C programs because of the lack of object lifetime annotations, so no, this statement can't be right. It is true that the borrow checker doesn't prevent ALL bugs though. Furthermore, the "bug" in this case is due to an unimplemented feature causing a flag to be silently ignored... It's not exactly something that any static analyser (or runtime ones for that matter) can prevent, unless an explicit assert/todo is added to the codepath.
- StopDisinfo910 1y ago
  Well, you can annotate C code to do a lot more than lifetime annotations today. The tooling for C analysis is best in class. And even without annotations, you can prove safe a lot of constructs by being conservative in your analysis especially if there is no concurrency involved. Note that I wasn't specifically commenting about this specific issue. It's more about my general fatigue regarding people implying that rewrite in Rust are always better or should be done. I like Rust but the trendiness surrounding it is annoying.
  - unscaled 1y ago
    You can do a lot of things. Yes, there are formally verified programs and libraries written in C. But most C programs are not, including the GNU coreutils (although they are battle-tested). It's just the effort involved is higher and the learning curve for verifying C code correctly is staggering. Rust provides a pretty good degree of verification out-of-the-box for free. Like any trendy language, you've got some people exaggerating the powers of the borrow checker, but I believe Rust did generally bring out a lot of good outcomes. If you're writing a new piece of systems software, Rust is pretty much a no-brainer. You could argue for a language like Zig (or Go where you're fine fine with a GC and a bit more boilerplate), but that puts even more spotlight on the fact that C is just not viable choice for most new programs anymore. The Rewrites-in-Rust are more controversial and they are just as much as they are hyped here on HN, but I think many of them brought a lot of good to the table. It's not (just?) because the C versions were insecure, but mostly because a lot of these new Rust tools replaced C programs that had become quite stagnant. Think of ripgrep, exa/eza, sd, nushell, delta and difft, dua/dust, the various top clones. And these are just command line utilities. Rewriting something in Rust is not an inherently bad idea of what you are replacing clearly needs a modern makeover or the component is security critical and the code that you are replacing has a history of security issues. I was always more skeptical about the coreutils rewrite project because the only practical advantage they can bring to the table is more theoretical safety. But I'm not convinced it's enough. The Rust versions are guaranteed to not have memory or concurrency related bugs (unless someone used unverified unsafe code or someone did something very silly like allocating a huge array and creating their own Von Neumann Architecture emulator just to prove you can write unsafe code in Rust). That's great, but they are also more likely to have compatibility bugs with the original tools. The value proposition here is quite mixed. On the other hand, I think that if Ubuntu and other distros persist in trying to integrate these tools the long-term result will be good. We will get a more maintainable codebase for coreutils in the future.
  - Avamander 1y ago
    > Well, you can annotate C code to do a lot more than lifetime annotations today. The tooling for C analysis is best in class. Where can I see these annotations for coreutils?
- consp 1y ago
  > It is true that the borrow checker doesn't prevent ALL bugs though. True, but "prevents all bugs" is that what the debate pretty much digests to in the "rust is better" debate. So you end up with rewrites of code which introduce errors any programmer in any language can make and since you do a full rewrite that WILL happen no matter what you do. If that's acceptable fine, otherwise not. But you cannot hide from it.
  - pepoluan 1y ago
    The "rust is better" point is always "prevent memory-related bugs from happening". Memory-related bugs is, like, 70% of bugs found in programs written in C and C++. So, by rewriting in Rust, you prevent 70% of new bugs from happening, because a whole class of bugs just cease to exist.
    - rurban 1y ago
      In safe rust, yes. But in unsafe rust, no guarantees. And as long as rust itself is unsafe, you cannot call it safe.
      - orangeboats 1y ago
        Congratulations to you on being the 10000th? person [0] to miss the point of unsafe/safe. 1. Unsafe doesn't mean the code is actually unsafe. It only tells you that the compiler itself cannot guarantee the correctness of it. 2. Unsafetiness tells the code reviewers to give a specific section of code more scrunity. Clippy also has an option that requires the programmer to put a comment to explain how the unsafe code is actually safe in the context. 3. And IF a bug does occur, it minimizes the amount of code you need to audit. [0]: https://xkcd.com/1053/ https://xkcd.com/1053/
    - gkbrk 1y ago
      Only if you don't use unsafe though. If you look at almost any real-world project written in Rust, you'll find tons and tons of `unsafe` in its dependency tree.
    - 1y ago
- rurban 1y ago
  You don't silently allow unhandled args. You do coverage testing, which would have found the missing date -r path. You do proper code review, which would have found the missing date -r path. And many coreutils options will not be implemented at all. ENOFIX
  - orangeboats 1y ago
    >You do coverage testing, which would have found the missing date -r path. The original coreutils test suite didn't cover the -r path. The same bug would have not been statically discovered in most programming languages, except perhaps the highly functional ones like Haskell. >You do proper code review, which would have found the missing date -r path. And in an ideal world there would be no bugs at all. This is pointless -- we all know that we need to do a proper code review, but humans make errors.
    - xorcist 1y ago
      Then any replacement project should start with implementing a better test suite in order to know what you're doing. That has been the case with many other utilities such as ntp. And it should most certainly not be possible to declare options and leave them as empty placeholders. That should be flagged just like an unused variable is flagged. That is a problem with whatever option library they chose to use. That alone should disqualify it from being a replacement yet. We're talking about a stable operating system used in production here. This is simply wrong on so many levels.
      - orangeboats 1y ago
        >Then any replacement project should start with implementing a better test suite in order to know what you're doing "Then any replacement project should not include bugs in their code." Like I said before, broad statements like these are borderline pointless. Of course we all know the should, the real problem is how -- how can you realistically make a "better test suite" when your goal is to create a bug-for-bug compatible replacement project? And given the size of the original project, how should a better test suite be created? >That is a problem with whatever option library they chose to use. Instead of being vague, why not show a precise example of what you are talking about?
timeon 1y ago
Is it really battle tested?
atoav 1y ago
If you read my comment with a little care, you may realize that I said nothing about replacing the software, I only spoke about writing it. In my own Distro I wouldn't replace coreutils with a Rust rewrite either at this point. On the borrow checker: It doesn't prevent logic errors as is commonly understood. These errors are what careful use of Rusts type system could potentially prevent in many cases, but you can write Rust without leveraging it successfully. The Rust compiler is an impressive problem-avoidance tool, but there are classes of problems even it can't prevent from happening. BLet us not fall into the trap of thinking thst just because the Rust compiler fails to prevent all issues, we should therefore abandon it. We shouldn't forget our shared history of mistakes rustc would have prevented (excerpt): - CVE-2025-5278, sort: heap buffer under-read in begfield(), Out-of-bounds heap read in traditional key syntax - CVE-2024-0684, split: heap overflow in line_bytes_split(), Out-of-bounds heap write due to unchecked buffer handling - CVE-2015-4042, sort: integer overflow in keycompare_mb(), Overflow leading to potential out-of-bounds and DoS If we were civil engineers with multiple bridge collapses in our past and then, we finally had developed a tool that reliably prevents a certain especially dangerous and common type of bridge collapse, we would be in the wrong profession if we scoffed at the use of the tool. Whether it is Ruet or some C checker isn't really the point here. The point is building stable, secure and performant software others can rely on. Any new method to achieve this more reliably has to be tested. Ideally in an environment where harm is low.
- delamon 1y ago
  It is worth noting, that all three CVEs could be prevented by simple bounds checking at runtime. Preventing them does not require borrow checker or any other Rust fancy features.
  - pdimitar 1y ago
    It is also worth noting that theoreticals don't help such discussions either. Yes, C programmers can do much more checks. The reality on the ground is -- they do not. Forcing checks by the compiler seems to be the only historically proven method of making programmers pay more attention. If you can go out there and make _all_ C code utilize best-in-class static checkers, by all means, go and do so. The world would be a much better place.
mrkeen 1y ago
> I’m still shocked by the number of people who seem to believe that the borrow checker is some kind of magic. It shouldn't be magic. It should be routine and boring, like no-nulls, pure functions, static typing and unit tests.
- StopDisinfo910 1y ago
  From my point of view, no, it shouldn’t be routine. Lifetime annotations and borrow checking are pretty far from the sweet spot of easy to deploy, useful and get out of the way when it comes to static analysis. Honestly, Ada is a far better choice than Rust when it comes to the safety/usability ratio and you can even add Spark on top which Rust has no equivalent of. But somehow we are saddled with the oversold fashion machine even when it makes no sense. I mean, look at the discussion. It’s full of people who don’t even know what static analysis is but come explaining to me that I am a C zealot stuck in the past and ignorant of the magnificence of our lord and saviour Rust. I don’t even use C. I don’t care that people rewrite stuff become they want to be cool. If they maintain them, it’s their responsibility and their time. I do care about distribution replacing things with untested things to sound cool however. That’s shoddy work. I also deeply disagree that pure functions should be the norm as an Ocaml programmer. They have their place but are no panacea either. That’s the Haskell hype instead of Rust hype this time.
awalGarg 1y ago
> I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. I'd be very interested in reading more about this. Could you please explain what are these checks and how they are qualitatively and quantitatively better than the default rustc checks? Please note that this is about checks on the codebase itself - not system/integration tests which are of course already applicable against alternative implementations.
pdimitar 1y ago
Claiming without evidence that something is battle-tested while also claiming the competition is "trendy" does not help any argument you might be attempting to make. I am trying to read your comments charitably but I am mostly seeing generalizations which makes it difficult to extract useful info from your commentary. We can start by dropping dismissive language like "trendy" and "magic", "fashion" and "Rust kids". We can also continue by saying that "believing the borrow checker is some kind of magic" is not an interesting thing to say as it does not present any facts or advance any discussion. What you "assure" us of is also inconsequential. One fact remains: there are a multitude of CVEs that, if the program was written in Rust, would not happen. I don't think anyone serious ever claimed that logic bugs are prevented by Rust. People are simply saying: "Can we just have less possible bugs by the virtue of the program compiling, please?" -- and Rust gives them that. What's your objection to that? And let us leave aside your seeming personal annoyance of whatever imaginary fandom you might be seeing. Let us stick to technical facts.
- danudey 1y ago
  The objections I see against Rust and Rust rewrites of things remind me a lot of the objections I saw against Linux and Linux users by Windows users, and against macOS and macOS users by Linux users. Dismissive language and denegrating comments without any technical backing; assertions of self-superiority. "It's a toy", "it's not mature", "it's a worse version of blah blah", "my thing does stuff it doesn't do and that's important, but it does things my thing doesn't do and that's irrelevant". Honestly it's at the point where I see someone complaining about a Rust rewrite and I just go ahead and assume that they're mouthing off about something because they think it's trendy and they think it's cool to hate things people like. I hate being prejudicial about comments but I don't have the energy to spend trying to figure out if someone is debating in good faith or not when it seems to so rarely be the case.
  - pdimitar 1y ago
    My impression is exactly the same. For multiple years now I keep seeing grandiose claims about "Rust fandom" and all I ever see in those threads are... the C people who complain about that Rust fandom that I cannot for the life of me find in a 300+ comments thread. It's really weird, at one point I started asking myself if many comments are just hidden from me. Then I just shrugged it off and concluded that it's plain old human bias and "mine is good, yours is bad" tribe mentality and figured it's indeed not worth my time and energy to do further analysis on tribal instinctive behaviour that's been well-explained in literature for like a century at this point. I have no super strong feelings for or against Rust, by the way. I have used it to crushing success exactly where it shines and for that it got my approval. But I also work a lot with Elixir and I would rarely try to make a web app with Rust; multiple PLs have the frameworks that make this much better and faster and more pleasant to do. But it does make me wonder: what stake do these people have in the whole thing? Why do they keep mouthing off about some imaginary zealots that are nowhere to be found?
hulitu 1y ago
> key word being untested. That's why they (still) have users. If it works so well for Microsoft, why wouldn't work for Ubuntu ?
steveklabnik 1y ago
> I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. Yet, this effort has still found bugs in the upstream project! No codebase is perfect.
tracker1 1y ago
This bug was missed because there wasn't a test case in the original.

orangeboats 1y ago

> I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. Some checks are pretty much impossible to do statically for C programs because of the lack of object lifetime annotations, so no, this statement can't be right. It is true that the borrow checker doesn't prevent ALL bugs though. Furthermore, the "bug" in this case is due to an unimplemented feature causing a flag to be silently ignored... It's not exactly something that any static analyser (or runtime ones for that matter) can prevent, unless an explicit assert/todo is added to the codepath.

StopDisinfo910 1y ago
Well, you can annotate C code to do a lot more than lifetime annotations today. The tooling for C analysis is best in class. And even without annotations, you can prove safe a lot of constructs by being conservative in your analysis especially if there is no concurrency involved. Note that I wasn't specifically commenting about this specific issue. It's more about my general fatigue regarding people implying that rewrite in Rust are always better or should be done. I like Rust but the trendiness surrounding it is annoying.
- unscaled 1y ago
  You can do a lot of things. Yes, there are formally verified programs and libraries written in C. But most C programs are not, including the GNU coreutils (although they are battle-tested). It's just the effort involved is higher and the learning curve for verifying C code correctly is staggering. Rust provides a pretty good degree of verification out-of-the-box for free. Like any trendy language, you've got some people exaggerating the powers of the borrow checker, but I believe Rust did generally bring out a lot of good outcomes. If you're writing a new piece of systems software, Rust is pretty much a no-brainer. You could argue for a language like Zig (or Go where you're fine fine with a GC and a bit more boilerplate), but that puts even more spotlight on the fact that C is just not viable choice for most new programs anymore. The Rewrites-in-Rust are more controversial and they are just as much as they are hyped here on HN, but I think many of them brought a lot of good to the table. It's not (just?) because the C versions were insecure, but mostly because a lot of these new Rust tools replaced C programs that had become quite stagnant. Think of ripgrep, exa/eza, sd, nushell, delta and difft, dua/dust, the various top clones. And these are just command line utilities. Rewriting something in Rust is not an inherently bad idea of what you are replacing clearly needs a modern makeover or the component is security critical and the code that you are replacing has a history of security issues. I was always more skeptical about the coreutils rewrite project because the only practical advantage they can bring to the table is more theoretical safety. But I'm not convinced it's enough. The Rust versions are guaranteed to not have memory or concurrency related bugs (unless someone used unverified unsafe code or someone did something very silly like allocating a huge array and creating their own Von Neumann Architecture emulator just to prove you can write unsafe code in Rust). That's great, but they are also more likely to have compatibility bugs with the original tools. The value proposition here is quite mixed. On the other hand, I think that if Ubuntu and other distros persist in trying to integrate these tools the long-term result will be good. We will get a more maintainable codebase for coreutils in the future.
- Avamander 1y ago
  > Well, you can annotate C code to do a lot more than lifetime annotations today. The tooling for C analysis is best in class. Where can I see these annotations for coreutils?
consp 1y ago
> It is true that the borrow checker doesn't prevent ALL bugs though. True, but "prevents all bugs" is that what the debate pretty much digests to in the "rust is better" debate. So you end up with rewrites of code which introduce errors any programmer in any language can make and since you do a full rewrite that WILL happen no matter what you do. If that's acceptable fine, otherwise not. But you cannot hide from it.
- pepoluan 1y ago
  The "rust is better" point is always "prevent memory-related bugs from happening". Memory-related bugs is, like, 70% of bugs found in programs written in C and C++. So, by rewriting in Rust, you prevent 70% of new bugs from happening, because a whole class of bugs just cease to exist.
  - rurban 1y ago
    In safe rust, yes. But in unsafe rust, no guarantees. And as long as rust itself is unsafe, you cannot call it safe.
    - orangeboats 1y ago
      Congratulations to you on being the 10000th? person [0] to miss the point of unsafe/safe. 1. Unsafe doesn't mean the code is actually unsafe. It only tells you that the compiler itself cannot guarantee the correctness of it. 2. Unsafetiness tells the code reviewers to give a specific section of code more scrunity. Clippy also has an option that requires the programmer to put a comment to explain how the unsafe code is actually safe in the context. 3. And IF a bug does occur, it minimizes the amount of code you need to audit. [0]: https://xkcd.com/1053/ https://xkcd.com/1053/
  - gkbrk 1y ago
    Only if you don't use unsafe though. If you look at almost any real-world project written in Rust, you'll find tons and tons of `unsafe` in its dependency tree.
  - 1y ago
rurban 1y ago
You don't silently allow unhandled args. You do coverage testing, which would have found the missing date -r path. You do proper code review, which would have found the missing date -r path. And many coreutils options will not be implemented at all. ENOFIX
- orangeboats 1y ago
  >You do coverage testing, which would have found the missing date -r path. The original coreutils test suite didn't cover the -r path. The same bug would have not been statically discovered in most programming languages, except perhaps the highly functional ones like Haskell. >You do proper code review, which would have found the missing date -r path. And in an ideal world there would be no bugs at all. This is pointless -- we all know that we need to do a proper code review, but humans make errors.
  - xorcist 1y ago
    Then any replacement project should start with implementing a better test suite in order to know what you're doing. That has been the case with many other utilities such as ntp. And it should most certainly not be possible to declare options and leave them as empty placeholders. That should be flagged just like an unused variable is flagged. That is a problem with whatever option library they chose to use. That alone should disqualify it from being a replacement yet. We're talking about a stable operating system used in production here. This is simply wrong on so many levels.
    - orangeboats 1y ago
      >Then any replacement project should start with implementing a better test suite in order to know what you're doing "Then any replacement project should not include bugs in their code." Like I said before, broad statements like these are borderline pointless. Of course we all know the should, the real problem is how -- how can you realistically make a "better test suite" when your goal is to create a bug-for-bug compatible replacement project? And given the size of the original project, how should a better test suite be created? >That is a problem with whatever option library they chose to use. Instead of being vague, why not show a precise example of what you are talking about?

timeon 1y ago

Is it really battle tested?

atoav 1y ago

If you read my comment with a little care, you may realize that I said nothing about replacing the software, I only spoke about writing it. In my own Distro I wouldn't replace coreutils with a Rust rewrite either at this point. On the borrow checker: It doesn't prevent logic errors as is commonly understood. These errors are what careful use of Rusts type system could potentially prevent in many cases, but you can write Rust without leveraging it successfully. The Rust compiler is an impressive problem-avoidance tool, but there are classes of problems even it can't prevent from happening. BLet us not fall into the trap of thinking thst just because the Rust compiler fails to prevent all issues, we should therefore abandon it. We shouldn't forget our shared history of mistakes rustc would have prevented (excerpt): - CVE-2025-5278, sort: heap buffer under-read in begfield(), Out-of-bounds heap read in traditional key syntax - CVE-2024-0684, split: heap overflow in line_bytes_split(), Out-of-bounds heap write due to unchecked buffer handling - CVE-2015-4042, sort: integer overflow in keycompare_mb(), Overflow leading to potential out-of-bounds and DoS If we were civil engineers with multiple bridge collapses in our past and then, we finally had developed a tool that reliably prevents a certain especially dangerous and common type of bridge collapse, we would be in the wrong profession if we scoffed at the use of the tool. Whether it is Ruet or some C checker isn't really the point here. The point is building stable, secure and performant software others can rely on. Any new method to achieve this more reliably has to be tested. Ideally in an environment where harm is low.

delamon 1y ago
It is worth noting, that all three CVEs could be prevented by simple bounds checking at runtime. Preventing them does not require borrow checker or any other Rust fancy features.
- pdimitar 1y ago
  It is also worth noting that theoreticals don't help such discussions either. Yes, C programmers can do much more checks. The reality on the ground is -- they do not. Forcing checks by the compiler seems to be the only historically proven method of making programmers pay more attention. If you can go out there and make _all_ C code utilize best-in-class static checkers, by all means, go and do so. The world would be a much better place.

mrkeen 1y ago

> I’m still shocked by the number of people who seem to believe that the borrow checker is some kind of magic. It shouldn't be magic. It should be routine and boring, like no-nulls, pure functions, static typing and unit tests.

StopDisinfo910 1y ago
From my point of view, no, it shouldn’t be routine. Lifetime annotations and borrow checking are pretty far from the sweet spot of easy to deploy, useful and get out of the way when it comes to static analysis. Honestly, Ada is a far better choice than Rust when it comes to the safety/usability ratio and you can even add Spark on top which Rust has no equivalent of. But somehow we are saddled with the oversold fashion machine even when it makes no sense. I mean, look at the discussion. It’s full of people who don’t even know what static analysis is but come explaining to me that I am a C zealot stuck in the past and ignorant of the magnificence of our lord and saviour Rust. I don’t even use C. I don’t care that people rewrite stuff become they want to be cool. If they maintain them, it’s their responsibility and their time. I do care about distribution replacing things with untested things to sound cool however. That’s shoddy work. I also deeply disagree that pure functions should be the norm as an Ocaml programmer. They have their place but are no panacea either. That’s the Haskell hype instead of Rust hype this time.

awalGarg 1y ago

> I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. I'd be very interested in reading more about this. Could you please explain what are these checks and how they are qualitatively and quantitatively better than the default rustc checks? Please note that this is about checks on the codebase itself - not system/integration tests which are of course already applicable against alternative implementations.

pdimitar 1y ago

Claiming without evidence that something is battle-tested while also claiming the competition is "trendy" does not help any argument you might be attempting to make. I am trying to read your comments charitably but I am mostly seeing generalizations which makes it difficult to extract useful info from your commentary. We can start by dropping dismissive language like "trendy" and "magic", "fashion" and "Rust kids". We can also continue by saying that "believing the borrow checker is some kind of magic" is not an interesting thing to say as it does not present any facts or advance any discussion. What you "assure" us of is also inconsequential. One fact remains: there are a multitude of CVEs that, if the program was written in Rust, would not happen. I don't think anyone serious ever claimed that logic bugs are prevented by Rust. People are simply saying: "Can we just have less possible bugs by the virtue of the program compiling, please?" -- and Rust gives them that. What's your objection to that? And let us leave aside your seeming personal annoyance of whatever imaginary fandom you might be seeing. Let us stick to technical facts.

danudey 1y ago
The objections I see against Rust and Rust rewrites of things remind me a lot of the objections I saw against Linux and Linux users by Windows users, and against macOS and macOS users by Linux users. Dismissive language and denegrating comments without any technical backing; assertions of self-superiority. "It's a toy", "it's not mature", "it's a worse version of blah blah", "my thing does stuff it doesn't do and that's important, but it does things my thing doesn't do and that's irrelevant". Honestly it's at the point where I see someone complaining about a Rust rewrite and I just go ahead and assume that they're mouthing off about something because they think it's trendy and they think it's cool to hate things people like. I hate being prejudicial about comments but I don't have the energy to spend trying to figure out if someone is debating in good faith or not when it seems to so rarely be the case.
- pdimitar 1y ago
  My impression is exactly the same. For multiple years now I keep seeing grandiose claims about "Rust fandom" and all I ever see in those threads are... the C people who complain about that Rust fandom that I cannot for the life of me find in a 300+ comments thread. It's really weird, at one point I started asking myself if many comments are just hidden from me. Then I just shrugged it off and concluded that it's plain old human bias and "mine is good, yours is bad" tribe mentality and figured it's indeed not worth my time and energy to do further analysis on tribal instinctive behaviour that's been well-explained in literature for like a century at this point. I have no super strong feelings for or against Rust, by the way. I have used it to crushing success exactly where it shines and for that it got my approval. But I also work a lot with Elixir and I would rarely try to make a web app with Rust; multiple PLs have the frameworks that make this much better and faster and more pleasant to do. But it does make me wonder: what stake do these people have in the whole thing? Why do they keep mouthing off about some imaginary zealots that are nowhere to be found?

hulitu 1y ago

> key word being untested. That's why they (still) have users. If it works so well for Microsoft, why wouldn't work for Ubuntu ?

steveklabnik 1y ago

> I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. Yet, this effort has still found bugs in the upstream project! No codebase is perfect.

tracker1 1y ago

This bug was missed because there wasn't a test case in the original.