5 ms·

And you run the risk or introducing new bugs as memory bugs aren't the only bugs there are plus rust doesn't catch all of them.

by nyberg 5y ago

rapsey 5y ago
When your entire platform is plagued by security issues in one component for years. Issues that at the end of the day are causing huge personal harm to your customers. Perhaps it is time to suck it up and rewrite the damn thing in a memory safe language.
- hulitu 5y ago
  A great line in a great movie "It is not economicly viable"
  - shadilay 5y ago
    In other word the 'cost' reputational or monetary of a few dead journalists/activists is less than that it would take to make it safe.
roca 5y ago
There is a bit of a risk of new bugs that Rust doesn't catch, but if your development process is at least modestly competent you'll have a large suite of automated tests for the bugs you found in the previous iteration of the software, which you can reapply to the new Rust code.
- jmull 5y ago
  It’s the new bugs that didn’t exist in the original code that you need to be concerned about. Consider any long-lived complex library. Count the bugs fixed since initial release. That’s your baseline — you can expect that order of magnitude of bugs in the initial release of your rewrite. Perhaps a new language will eliminate some classes of bugs, so maybe you can cut that number in half or even to a quarter. But you need to come to terms with that number. Now add on the number of bugs due to compatibility. Image formats generally are not tightly spec’ed, meaning the de facto standard libraries become the de facto standard — that is, the library being rewritten. Rewrites are a long road that starts off one step forward and three steps back. It could sill be worth it, depending on the case. But an effort to “rewrite in rust” that doesn’t account for this will fail.
  - roca 5y ago
    > That’s your baseline — you can expect that order of magnitude of bugs in the initial release of your rewrite. My point was that the test suite you start with for your rewrite will be (or at least should be) a lot better than the test suite you had when you started writing the original code. The spec will likely be better too. Also, you can learn a lot from the previous iteration. These effects, plus the benefits of the new language, have the potential to reduce the bug count dramatically. Maybe even by an order of magnitude. Having said that, you're certainly right that there are some steps back and the net cost or benefit is likely highly context-dependent. It would be great to have more data on projects that have done this, to help people estimate the costs and benefits in their context.
  - zarzavat 5y ago
    Your cost benefit analysis is off. Which would you rather have, a broken jpeg once in a blue moon or a hacked phone? Writing image decoders for several formats is hard but it's not so hard that a trillion dollar company can't write a good one.

And you run the risk or introducing new bugs as memory bugs aren't the only bugs there are plus rust doesn't catch all of them.

by nyberg 5y ago

And you run the risk or introducing new bugs as memory bugs aren't the only bugs there are plus rust doesn't catch all of them.

rapsey 5y ago

When your entire platform is plagued by security issues in one component for years. Issues that at the end of the day are causing huge personal harm to your customers. Perhaps it is time to suck it up and rewrite the damn thing in a memory safe language.

hulitu 5y ago
A great line in a great movie "It is not economicly viable"
- shadilay 5y ago
  In other word the 'cost' reputational or monetary of a few dead journalists/activists is less than that it would take to make it safe.

roca 5y ago

There is a bit of a risk of new bugs that Rust doesn't catch, but if your development process is at least modestly competent you'll have a large suite of automated tests for the bugs you found in the previous iteration of the software, which you can reapply to the new Rust code.

jmull 5y ago
It’s the new bugs that didn’t exist in the original code that you need to be concerned about. Consider any long-lived complex library. Count the bugs fixed since initial release. That’s your baseline — you can expect that order of magnitude of bugs in the initial release of your rewrite. Perhaps a new language will eliminate some classes of bugs, so maybe you can cut that number in half or even to a quarter. But you need to come to terms with that number. Now add on the number of bugs due to compatibility. Image formats generally are not tightly spec’ed, meaning the de facto standard libraries become the de facto standard — that is, the library being rewritten. Rewrites are a long road that starts off one step forward and three steps back. It could sill be worth it, depending on the case. But an effort to “rewrite in rust” that doesn’t account for this will fail.
- roca 5y ago
  > That’s your baseline — you can expect that order of magnitude of bugs in the initial release of your rewrite. My point was that the test suite you start with for your rewrite will be (or at least should be) a lot better than the test suite you had when you started writing the original code. The spec will likely be better too. Also, you can learn a lot from the previous iteration. These effects, plus the benefits of the new language, have the potential to reduce the bug count dramatically. Maybe even by an order of magnitude. Having said that, you're certainly right that there are some steps back and the net cost or benefit is likely highly context-dependent. It would be great to have more data on projects that have done this, to help people estimate the costs and benefits in their context.
- zarzavat 5y ago
  Your cost benefit analysis is off. Which would you rather have, a broken jpeg once in a blue moon or a hacked phone? Writing image decoders for several formats is hard but it's not so hard that a trillion dollar company can't write a good one.