It's a good point in general, but in this case it's not clear if the cost of re-writing the existing codebase is less than the cost of staying with a memory-unsafe language.

We know from past experience that it takes an extreme amount of time and effort to harden a browser written in C++ against malicious web content. The Ladybird codebase is not particularly "old" in any sense of the word. Judging by Github's stats most of the code is less than 4 years old and it is still a long ways from being ready for general use. I think it's safe to say Ladybird still has a vast amount of work to be done fixing vulnerabilities that arise from lack of memory safety.

I find it quite plausible that the cost of re-writing the existing code in Rust is less than the cost of fixing all of the current and future bugs in the C++ codebase that Rust would catch at compile time.

The only exception is if you have 500k LOC in a language whose runtime is going to be deprecated on all platforms overnight.

I'm referring to the uh, retrospectively unfortunate decision I made in 2007 to start building large scale business app frontends in AS3.

I guess I should be thankful for the work, having to rewrite everything in TS from scratch a decade later. (At least the backends didn't have to be torn down).

Old code does acquire new bugs by sitting in your hard drive, since it interfaces with dozens of libraries and APIs that don't care about how well test the code is: every path of code is dependent on multiple components playing well and following standards/APIs/formats that old code has no knowledge of. Also, the mountain of patch-fixes and "workarounds" in the end force the programmers into a corner, where development is hobbled by constraints and quirks of "battle-tested" code, that will be thrown away as soon as it couldn't support fancy new feature X or cannot use fancy new library API without extra layers of indirection.

This was more C++ versus "we haven't picked what we are going to write this in"