I think of this differently. Assume that there's a situation where your language has to change, whether because of acquisition or scaling or hosting or lack of

I think of this differently. Assume that there's a situation where your language has to change, whether because of acquisition or scaling or hosting or lack of developers or licensing or whatever. How do you switch? And, more importantly, can you do it in a granular manner? From Spolsky: "First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code." Think about your system as a series of pieces and keep the as (appropriately) decoupled as you can. Then, when you find a technical/business/legal bottleneck that is tied to a language issue, you can swap out that piece and keep moving. I love being able to confidently say: "Well, our integration point is always through the db, so if the mixer needs to be faster or rewritten in C++ we can do that. If retrieval needs to be pulled out onto another machine, we can do that. If you need it rewritten in Python, here are the five big pieces, and each one can be moved over independently."