"Rewrite everything in Rust" is not that useful, but "write new code in Rust so you're not digging deeper holes" and "rewrite your most sensitive code in Rust" is pretty good advice.

Define "new" code - rust has no ABI stability story, and doesn't have a path to interact with any language other than C, so new code in existing libraries may not be feasibly written in rust.

Anyway, Apple's safe language is Swift, which they are clearly pushing and using more of as time goes by.

You can expose a C ABI, and so it’s a drop-in replacement for things that used to talk to C code. Which is virtually everything.

not on Mac/I/watch/tvOS where much of the core platform API is objective-c (Which swift has first class support for), and C++ (because of poor 90s decisions).

But also missing the point that you can't implement a subclass or what have you in rust, and if every interface you have is C then you have an exercise in mass unsafe code.

Both Objective C and C++ can call things that use the C ABI. Rust code ships in real products on those platforms.

Apple is using Rust too. We don't know how much, because Apple.

> doesn't have a path to interact with any language other than C

https://crates.io/crates/cxx

> so new code in existing libraries may not be feasibly written in rust

Not sure exactly what you mean here.

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.

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.

A great line in a great movie "It is not economicly viable"

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.

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.

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.

> 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.

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.