Jon Udell is frustrated:

The proliferation of language runtimes (virtual machines) both fascinates and frustrates me. Here on my Windows machine I use the .NET Common Language Runtime, the Java VM, the Flash player, and one VM per dynamic language (e.g., Python, JavaScript). Over on my Mac, subtract .NET but don't (yet) add Mono. On servers, add the PHP and Ruby VMs.

When people "port" applications and frameworks from one language to another, what they're really doing, in many cases, is transferring capability from one VM to another. Case in point: TrimPath Junction, a "clone or port of the terrific Ruby on Rails web MVC framework into JavaScript." Language preference wasn't the reason to emulate Rails in JavaScript. Rather, the motivation was to bring Rails-like capability to the only VM available in the browser, and thus to enable single-page applications.

That frustration is why I like to say that design is language specific - unless you want to do a ton of work to take a language capability and port it. Multi-language VM's are a pretty hard thing, too - the VM's that exist were very much designed with their main language in mind - Java on the JVM, C# on the CLR. Sure, there's a port of Python to both - and in the case of the CLR, it sounds like the author is, for all intents and purposes, creating a new VM on top of the CLR - i.e., treating it as another hardware platform.

We looked seriously at using the CLR as a place to run Cincom Smalltalk, but found that it was utterly unsuitable - we would have had to treat the CLR as a new platform, and write a new VM on top of it. The CLR simply doesn't have suitable support for a language like Smalltalk. Don't even ask about the JVM - it's been frozen for years, and any Smalltalk running on it is going to be slow. Really slow.

Neither Microsoft nor Sun are acting truly motivated to support dynamic languages - at least, not if you look at what they actually do.