> In fact the entire narrative of 'you'll get it better the second time' is nonsense, the software being rewritten was usually written for the first time by totally different people, and the rewriters weren't around for it or most of the bugfixes. They're all starting fresh, the development process is nearly the same as the original blank slate was - if they get it right with Rust, then Rust is an active ingredient in getting it right!

Yes, this is a serious flaw in the author's argument. Does he think the exact same team that built version 1.0 in C++ is the one writing 2.0 in Rust? Maybe that happens sometimes, I guess, but to draw a general lesson from that seems weird.

Well, I think some people underestimate how old and badly written a lot of software can be.

I've seen some seriously bad legacy code bases. In fact, I've spent many years of my career hired specifically to redesigning and rewriting software. Either legacy code or code that wasn't written by pro software engineers in the first place (e.g. engineers of other fields or scientists with various specializations).

And thus, I also observe that many people aren't aware how much software (in production) was created by people for whom creating software is a secondary or tertiary interest and skill at best.

And yes, typically it gets much better when rewritten later and by a pro.

Not all software needs that, it doesn't always work. But it needs to happen quite often for the software to stay maintainable and extensible with new features. In a lot of these cases only the original author would even dare to touch it. Good for short term job security, bad for the company.

And it isn't a requirement for the original authors to be involved (though that helps a lot usually).

I myself rewrite my own code quite often and tend to refactor and iterate on it a lot. The first shot is rarely good. But it get's good after a while.