Unfortunately, that's not how languages work. There may be language equivalence classes (that would put, say, Ruby, Python and JS in the same class, C, C++ and Rust in another, and Java, C# and Go in a third), but languages from different classes can't just be translated from one to the other. First, a program written in one language isn't just a description of an algorithm, but a description of the algorithm plus language-specific information that's supposed to help the particular platform execute the algorithm efficiently. Second, there are essential runtime differences that can't be easily ported, such as a threading model and a memory model -- and those may significantly affect the suitability of an algorithm for a certain language. Finally, there are fundamental differences in the appropriateness of certain algorithms; specifically, imperative algorithms can't be automatically translated to pure-functional algorithms without possibly changing their time and space asymptotic complexity.

In short, there's a lot more to a computer program than a description of an algorithm, and even algorithms vary considerably in their suitability depending on the language/runtime executing them. Even if you could solve the first problem, you're still left with the second.

I do agree with the premise, though: unless your new language/runtime is so revolutionary that it reduces development cost dramatically, fracturing the ecosystem is often too high a price to pay for merely a "nice" improvement. The problem is that many languages claim dramatic cost reductions, but it usually takes years to learn whether or not they deliver. The reason for that is not just the number of data points, but the fact that the cost of software is spread across a codebase's lifetime (10 years is about the average lifespan of a production system codebase), and how development looks -- and what activities contribute to costs -- in the first and second year is very different from how it looks in the sixth.