At a technical level, virtual machines are not the panacea many folks seem to think. Certainly, VM byte code languages are often simpler than silicon processor

At a technical level, virtual machines are not the panacea many folks seem to think. Certainly, VM byte code languages are often simpler than silicon processors' machine languages; perhaps they offer safety guarantees; and perhaps they provide garbage collection. These are all big wins for language implementers targeting such VMs. But what no virtual machine will ever do is make modules written in different source languages work together transparently. Any time one module calls another module written in a different language, at least one side of that boundary needs to be written with a detailed understanding of both languages' semantics. Tiny details of the semantics influence the idioms people settle on in that language --- and interfaces are designed around those idioms. For example, JavaScript conditionals treat the empty array and the empty object as true, while Python conditionals treat them as false. Each of these facts shapes what people expect of a "natural" API in that language --- and that ensures that modules written in other languages will always "speak with an accent", or seem unnatural, at best. You can define a common data world, as the .NET CLR does, and extend each source language to cover that world, but the effect is to change each participant language into a gloss on the common data world. This is why CoffeeScript fits seamlessly into the JavaScript world: JavaScript's and CoffeeScript's data worlds are exactly the same. CoffeeScript cannot deviate from JavaScript's types and objects. Each programming language is like a city occupying an island: commerce within the city is much less expensive than commerce between islands. Although it's sometimes worth it, dealing with "foreigners" is confusing and risky. No VM will change that.