> If a rewrite is necessary, then the sooner you start the sooner you'll finish.
A 8-person team might easily rely on more C/C++ code than could be rewritten by them in 3 years. This jumps to 10-40 years if you include external Open Source codebases like Nginx.
So, the team needs to prioritize and to do things in steps. While they are rewriting some C/C++ code, they'll need to still maintain other code.
...and they need to solve enough business problems to keep the lights on.
> So, the team needs to prioritize and to do things in steps. While they are rewriting some C/C++ code, they'll need to still maintain other code.
Sure. But I don't think kind of portability-for-reliability work described in the article is effective work that should be prioritised. Yes, it will catch some bugs, but there's not actually much value in that.
Perhaps (though frankly I doubt it). But at the very least it's very possible to avoid the "everything is a security bug by default" phenomenon of C/C++ undefined behaviour; your program may still crash occasionally, but a clean crash is relatively benign compared to security bugs or even just silent data corruption.
> If it took many years to write a big C codebase, then a rewrite likely will take significant time too (or you'll drop many useful features and/or introduce new bugs). And most software project take more time than anticipated, rewrites is not an exception here. Isn't is a waste of money too, just another kind?
If a rewrite is necessary, then the sooner you start the sooner you'll finish. I'm coming from a view that a) C/C++ code is always insecure and cannot be made secure b) as exploitation improves along with everything else, running insecure code will become increasingly untenable. You could disagree with either premise.