Did you read what they wrote? Their point is that doing a fresh rewrite of old code in any language will often inherently fix some old issues - including memory safety ones.

Because it's a re-write, you already know all the requirements. You know what works and what doesn't. You know what kind of data should be laid out and how to do it.

Because of that, a fresh re-write will often erase bugs (including memory ones) that were present originally.

▲

puzzledobserver 5 days ago | parent [-]

That claim appears to contradict the second-system effect [0].

The observation is that second implementation of a successful system is often much less successful, overengineered, and bloated, due to programmer overconfidence.

On the other hand, I am unsure of how frequently the second-system effect occurs or the scenarios in which it occurs either. Perhaps it is less of a concern when disciplined developers are simply doing rewrites, rather than feature additions. I don't know.

[0] https://en.wikipedia.org/wiki/Second-system_effect

	▲	Night_Thastus 5 days ago \| parent \| next [-]
		I won't say the second-system effect doesn't exist, but I wouldn't say it applies every single time either. There's too many variables. Sometimes a rewrite is just a rewrite. Sometimes the level of bloat or feature-creep is tiny. Sometimes the old code was so bad that the rewrite fully offsets any bloat.
	▲	AnimalMuppet 4 days ago \| parent \| prev [-]
		The second system effect isn't that a rewrite necessarily has more bugs/problems. The second system effect is that a follow-on project with all of everybody's dreamed-of bells and whistles that everybody in marketing wants is going to have more problems/bugs, and may not even be finishable at all.