You’ve seen them before. Those stories of companies that switched from their early design language to some other, did a complete re-write of their money maker, and ended up with a much smaller code base. And as with scientific studies, especially in the field of nutrition, you can find an example for every combination that shows the new approach is “better”. So Rust delivers shorter code than Python, Go leads to a significant reduction in code size compared to Ruby and so on. Oh, and the new code is always faster, more stable and easier to maintain.
My problem with that? Stay with one language and just re-write your code. The results will be (mostly) the same.
The code replaced in those stories usually “grew in an organic fashion”, that is, it was cobbled together haphazardly. It works? Ship it! No time for refactorings. No time for getting rid of that ugly-yet-working-timer or the Thread.Sleep() loop. If you take such a piece of code and just clean it up, it will shrink and become more robust just by you taking the time to plan a little more ahead. You have a better understanding of the requirements. You have all those nagging thoughts still edged into your brain: If only I could do this part in that way. Would be oh so much better, but I can’t, because of that fubar over there that would have to be fixed first. And so on. By writing your code anew, you can address all those little points with the bosses’ blessings instead of slipping in a tiny refactoring under the radar now and then.
The verdict? I reduced a codebase of 250 kloc down to 69 kloc by staying in C#. From 79 kloc in Java down to 23 kloc, still Java. The language used does play a part in this, and the C# base, for example, might have come down to 10 kloc of Lisp or Python. But always keep in mind that there is a difference between essential and accidental complexity.