Your definition of "replace" is too strict: the idea of a successor language is not replacing all existing code, but rather making it possible for individual pr

Your definition of "replace" is too strict: the idea of a successor language is not replacing all existing code, but rather making it possible for individual projects to painlessly evolve from the old language to a new one. Some old code - whether entire inactive projects or inactive parts of active projects - may never get rewritten in the new language and that is OK.