All the code rewrites from the last several decades would like a word in return.

A bunch of those rewrites managed to miss critical things that were encoded in the existing logic in non-obvious ways. They broke a bunch of workflows that way.

A bunch of others went wildly over-budget and wound up getting shut down before they produced anything usable.

But surely the documentation will tell you all the use cases, and the expected inputs and outputs, right? Right? Oh, you don't have documentation like that? Yeah, then it's used in ways you don't know about, and your rewrite is likely to break them. (And that's true even if you do have such documentation, because it's incomplete.)

Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not.

"But this time we're going to use Rust!" Yeah, but the thing that makes rewrites so hard was never the language, so using Rust isn't going to actually fix it.

I agree with your take and want to add that "we want less CVEs" and "we want meaningful rewrites" are not necessarily at odds with each other. We can have both.

I'll also note that efforts like rewriting a lot of UNIX userland in Rust also introduces the benefits of rewrites -- you have to think super hard if you want that obscure command-line switch that only works in X way if another switch has another value or it does the thing Y if two other switches have these other values. I forgot the examples but that's what happened there: people figured "we will not implement command switches X and Y" and lo and behold, people using those tools never even noticed, myself included.

So, rewrites have positives as well. And not everyone doing rewrites is clueless.

> Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not.

This is a major reason why so many financial/healthcare/insurance/government institutions still runs COBOL software on mainframes. Many times, you're looking at what is essentially a monolith (in many parts, but everything is connected in some way) that was 50+ years in the making.

Rewriting it is a huge and extremely expensive task, and had it not been because COBOL is considered a "bad language" by the young people, and thereby causing problems with recruitment, i'm guesssing the mainframe would be around for 100+ years to come.

As it is now, these companies are forced to migrate away from COBOL, and most companies in the financial sector would probably go for Java, which is posed to becomming the new COBOL.

If you start a career today as a young COBOL programmer, you will most likely have a high salary (for your career) for your entire work life.

The mainframe is certainly on the way out, but it's a big beast to move, and most "estimates" i hear from financial institutions is that they plan to migrate away in 10-30 years, and predicting what happens in 30 years is kinda pointless. Suffice to say that the Mainframe and COBOL is probably here for another 30-50 years.