5 ms·

Why? Most of these "existing software" are tried and tested tools that have stood the test of time. Why rewrite them and introduce potential bugs? Write somethi

Why? Most of these "existing software" are tried and tested tools that have stood the test of time. Why rewrite them and introduce potential bugs? Write something new!

Jataman606 5y ago
Most of this are not actual rewrites, but "write-a-news", so they are not drop in replacements. Like ripgrep for example: it servers the same task, but is in some ways improvement over "tried and tested" grep.
coldtea 5y ago
Because they can be rewritten by removing legacy cruft, in a language that prevents the numerous security issues they had (and still have), and optimizing several things besides... Does anybody miss Sendmail? That had also "stood the test of time".
- dig1 5y ago
  Sendmail never stood the test of time and is pretty much abandoned now, replaced with Postfix. Guess in what language Postfix was written... The idea is that language will not solve poorly designed software, but a developer that knows what he is doing like Wietse did with Postix. And Postfix stood the test of time pretty well, considering how complex it is.
  - coldtea 5y ago
    >The idea is that language will not solve poorly designed software Another idea is that a software can have a great design but still be full of security holes. C allows for that. If we leave it to the "adequately advanced programmer" to avoid those, we're doing it wrong - with plenty of historical examples to prove this.
    - afarrell 5y ago
      Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. The only thing that will actually prevent security holes is attentive software engineers deliberately choosing to learn tools and practice habits to avoid security holes by design. The professional judgement of a lot of those engineers is leading them to choose to learn rust right now.
      - pdimitar 5y ago
        > Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. Absolutely. It's just that statistically the memory safety bugs have been the dominant percent of all the bugs, so rewriting core tools in a memory-safe language does make sense.
        afarrell 5y ago
        Indeed. Time & attention are limited resources. By eliminating the dominant class of bugs you have more time and attention for more subtle bugs.
        pdimitar 5y ago
        > Time & attention are limited resources. By eliminating the dominant class of bugs you have more time and attention for more subtle bugs. Beautifully articulated.
      - coldtea 5y ago
        >Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. No. But it will make sure there are no issues of the type buffer overflow and such. The rest, we can judge when the software is delivered.
        scoutt 5y ago
        > it will make sure https://www.cvedetails.com/vulnerability-list/vendor_id-19029/product_id-48677/Rust-lang-Rust.html https://www.cvedetails.com/vulnerability-list/vendor_id-1902... I'm not so sure.... And those are bugs from from people writing core stuff, like you know, the people who should know Rust better than you and me. People writing foundational code that your program will run on top of. Of special danger is the last CVE, that was rushed and backported into the last release. But nobody talks about it. I can imagine why. I can bet that the "but the bug happened within unsafe code" excuse will be the next Rust meme.
  - sbuk 5y ago
    Sendmail is now owend by Proofpoint and I can only assume it forms the basis of the MTAs for their gateway.
pdimitar 5y ago
OpenSSL was deemed as standing the test of time as well. Then Heartbleed happened. Rewriting in a memory-safe language is worth it. But it shouldn't be a religion, I completely agree on that.
- protomyth 5y ago
  I don't think anyone thought OpenSSL was good code even before Heartbleed. Bob Beck pointed that out in his LibreSSL talk https://youtu.be/GnBbhXBDmwU https://youtu.be/GnBbhXBDmwU
  - pdimitar 5y ago
    Then he's the exception, at least anecdotally in my career and life. Most C/C++ programmers I've known were ready to defend their code quality with their fists. They were in complete denial.
- oscargrouch 5y ago
  Heartbleed happen because the open source software used by everyone were left getting dust, with low maintenance and despite its popularity, nobody was paying or donating nothing to keep the project going. Even if Rust was invented in the 80's, and such a project was in it, the same could happen in one of those unsafe{} blocks a Rust project like this might need to use (and we are forgetting all the ordinary bugs even in the safe portions of the code). Sure, being in C might be a part of the problem, and this is a good space for tools like Rust to occupy more space, but there's a bigger picture or else Linux would be breaking all the time, and its a solid, big and complex piece of software that works pretty well because there's a lot of economical incentives to keep it going.
  - pdimitar 5y ago
    > with low maintenance and despite its popularity, nobody was paying or donating nothing to keep the project going.* There probably is a Wikipedia page describing this phenomena but I'll settle for calling it "the commodity effect": when something is very widely used then everybody assumes it has been improved to perfection and that it has no flaws (this is not exclusive to software engineering, it happens in many areas of life). > the same could happen in one of those unsafe{} blocks a Rust project like this might need to use Sure but they are much easier to search for and audit (like with e.g. `cargo-geiger`). That by itself is a win. Whereas C/C++ needs a special class of linters and scanners, a good chunk of which are paid (a deal-breaker for many software devs not because they're poor but because they don't want to pay for them out of their pocket, and their employer is blind to see the added value and buy those tools for them). > and we are forgetting all the ordinary bugs even in the safe portions of the code Only people with agenda forget about those. I worked with Rust in 3 companies in total so far and I've only seen serious, diligent, hard-working devs with attention to detail and a slight case of efficiency mania. :) And they were very mindful of potential bugs and we wrote a lot of tests of different kinds like acceptance/integration, unit, property, and probably others. No normal smart developer forgets that memory safety bugs are just one class of all the bugs. Turns out however that those are the most widespread bugs in general so IMO it is sensible to use a language that eliminates them by the mere virtue of compiling your program -- and not using unsafe{} in certain ways. As another poster said, time and attention are limited resources. By removing memory safety bugs from the picture our brains are now free to pay proper attention to the more subtle bugs.
beforeolives 5y ago
Hobby projects? I wonder how many of these projects match this pattern: 1. Rust is new and cool and I want to be a Rust developer. 2. There are almost no Rust jobs out there. 3. I don't have original ideas or any actual use cases for this language. 4. So I will rewrite something that already exists in it.
EamonnMR 5y ago
Writing something new in rust is harder than rewriting because you need to think a lot about your memory model up front. In other languages you can leak all the memory you want and then (maybe) figure enough of it out when you've already shipped/already deployed. In Rust you need to do the up front work, so instead of releasing a leaky program, you don't release a program at all. If there is an existing program you can make assumptions more readily.
ironmagma 5y ago
As many say, open source is about choice. There are no choices if there’s only one of each thing.

Why? Most of these "existing software" are tried and tested tools that have stood the test of time. Why rewrite them and introduce potential bugs? Write something new!

Jataman606 5y ago

Most of this are not actual rewrites, but "write-a-news", so they are not drop in replacements. Like ripgrep for example: it servers the same task, but is in some ways improvement over "tried and tested" grep.

coldtea 5y ago

Because they can be rewritten by removing legacy cruft, in a language that prevents the numerous security issues they had (and still have), and optimizing several things besides... Does anybody miss Sendmail? That had also "stood the test of time".

dig1 5y ago
Sendmail never stood the test of time and is pretty much abandoned now, replaced with Postfix. Guess in what language Postfix was written... The idea is that language will not solve poorly designed software, but a developer that knows what he is doing like Wietse did with Postix. And Postfix stood the test of time pretty well, considering how complex it is.
- coldtea 5y ago
  >The idea is that language will not solve poorly designed software Another idea is that a software can have a great design but still be full of security holes. C allows for that. If we leave it to the "adequately advanced programmer" to avoid those, we're doing it wrong - with plenty of historical examples to prove this.
  - afarrell 5y ago
    Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. The only thing that will actually prevent security holes is attentive software engineers deliberately choosing to learn tools and practice habits to avoid security holes by design. The professional judgement of a lot of those engineers is leading them to choose to learn rust right now.
    - pdimitar 5y ago
      > Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. Absolutely. It's just that statistically the memory safety bugs have been the dominant percent of all the bugs, so rewriting core tools in a memory-safe language does make sense.
      - afarrell 5y ago
        Indeed. Time & attention are limited resources. By eliminating the dominant class of bugs you have more time and attention for more subtle bugs.
        pdimitar 5y ago
        > Time & attention are limited resources. By eliminating the dominant class of bugs you have more time and attention for more subtle bugs. Beautifully articulated.
    - coldtea 5y ago
      >Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. No. But it will make sure there are no issues of the type buffer overflow and such. The rest, we can judge when the software is delivered.
      - scoutt 5y ago
        > it will make sure https://www.cvedetails.com/vulnerability-list/vendor_id-19029/product_id-48677/Rust-lang-Rust.html https://www.cvedetails.com/vulnerability-list/vendor_id-1902... I'm not so sure.... And those are bugs from from people writing core stuff, like you know, the people who should know Rust better than you and me. People writing foundational code that your program will run on top of. Of special danger is the last CVE, that was rushed and backported into the last release. But nobody talks about it. I can imagine why. I can bet that the "but the bug happened within unsafe code" excuse will be the next Rust meme.
- sbuk 5y ago
  Sendmail is now owend by Proofpoint and I can only assume it forms the basis of the MTAs for their gateway.

pdimitar 5y ago

OpenSSL was deemed as standing the test of time as well. Then Heartbleed happened. Rewriting in a memory-safe language is worth it. But it shouldn't be a religion, I completely agree on that.

protomyth 5y ago
I don't think anyone thought OpenSSL was good code even before Heartbleed. Bob Beck pointed that out in his LibreSSL talk https://youtu.be/GnBbhXBDmwU https://youtu.be/GnBbhXBDmwU
- pdimitar 5y ago
  Then he's the exception, at least anecdotally in my career and life. Most C/C++ programmers I've known were ready to defend their code quality with their fists. They were in complete denial.
oscargrouch 5y ago
Heartbleed happen because the open source software used by everyone were left getting dust, with low maintenance and despite its popularity, nobody was paying or donating nothing to keep the project going. Even if Rust was invented in the 80's, and such a project was in it, the same could happen in one of those unsafe{} blocks a Rust project like this might need to use (and we are forgetting all the ordinary bugs even in the safe portions of the code). Sure, being in C might be a part of the problem, and this is a good space for tools like Rust to occupy more space, but there's a bigger picture or else Linux would be breaking all the time, and its a solid, big and complex piece of software that works pretty well because there's a lot of economical incentives to keep it going.
- pdimitar 5y ago
  > with low maintenance and despite its popularity, nobody was paying or donating nothing to keep the project going.* There probably is a Wikipedia page describing this phenomena but I'll settle for calling it "the commodity effect": when something is very widely used then everybody assumes it has been improved to perfection and that it has no flaws (this is not exclusive to software engineering, it happens in many areas of life). > the same could happen in one of those unsafe{} blocks a Rust project like this might need to use Sure but they are much easier to search for and audit (like with e.g. `cargo-geiger`). That by itself is a win. Whereas C/C++ needs a special class of linters and scanners, a good chunk of which are paid (a deal-breaker for many software devs not because they're poor but because they don't want to pay for them out of their pocket, and their employer is blind to see the added value and buy those tools for them). > and we are forgetting all the ordinary bugs even in the safe portions of the code Only people with agenda forget about those. I worked with Rust in 3 companies in total so far and I've only seen serious, diligent, hard-working devs with attention to detail and a slight case of efficiency mania. :) And they were very mindful of potential bugs and we wrote a lot of tests of different kinds like acceptance/integration, unit, property, and probably others. No normal smart developer forgets that memory safety bugs are just one class of all the bugs. Turns out however that those are the most widespread bugs in general so IMO it is sensible to use a language that eliminates them by the mere virtue of compiling your program -- and not using unsafe{} in certain ways. As another poster said, time and attention are limited resources. By removing memory safety bugs from the picture our brains are now free to pay proper attention to the more subtle bugs.

beforeolives 5y ago

Hobby projects? I wonder how many of these projects match this pattern: 1. Rust is new and cool and I want to be a Rust developer. 2. There are almost no Rust jobs out there. 3. I don't have original ideas or any actual use cases for this language. 4. So I will rewrite something that already exists in it.

EamonnMR 5y ago

Writing something new in rust is harder than rewriting because you need to think a lot about your memory model up front. In other languages you can leak all the memory you want and then (maybe) figure enough of it out when you've already shipped/already deployed. In Rust you need to do the up front work, so instead of releasing a leaky program, you don't release a program at all. If there is an existing program you can make assumptions more readily.

ironmagma 5y ago

As many say, open source is about choice. There are no choices if there’s only one of each thing.