Total rewrites are almost always the wrong move. It may be true that they meet their stated objectives, but some of those objectives could have been achieved w

Total rewrites are almost always the wrong move. It may be true that they meet their stated objectives, but some of those objectives could have been achieved without a rewrite, and some of those objectives don't make sense. I've written plenty of single executables for multiple targets in Python. Figuring out how to do that would certainly have taken less time than the rewrite. Small resource usage may make sense, but they didn't relate it to any actual customer need, and given it was already running on RHEL, I doubt this was a reasonable goal. Unless it also needed to run on pocket calculators, the resource needs of a Python program are well within reason for most target environments. To be clear, I don't think Lua is a worse choice than Python for a new project; my objection is to the rewrite. There are problems with both languages. Sure, now packaging is easier, but when he runs into a hard problem that would have been solved by an existing Python library is he going to rewrite again? It's a junior developer mistake to blame issues on your tools and rewrite instead of getting things to work in your existing environment. Mature tools like Python (or even to a lesser extent Lua) are rarely the problem. There are certainly exceptions where there are serious problems such that changing tools makes sense. But none of the problems mentioned in the writeup are that. The bad part of the rewrite is that there is no possible way to know what was lost. There are edge cases which were discovered and handled in the old product that will have to be rediscovered in the new one. It sounds like they haven't lost any business over this, so it will be okay in the long run. But I suspect they could have done this a lot easier and cheaper. Just because it turned out okay doesn't mean this is an exemplary choice we should learn from.