I would love to see different programming language for computercraft to emerge, like JavaScript or Ruby.

I thing, that the best way to approach this would be, to separate core mod from language into mods like BuildCraft do (computercraft-core and computercraft-languageName).
Then the computer could potentially even run multiple languages, if they would be all installed!

Only if one fork the repo and replace by its own the virtual machine (from lua to nashhorn, for example).

Even knowing dan would never concord with this, i would love to see someone making a fork of CC but with Javascript as the main language.

I can see this one being real. The big point is, that the computercraft team should only develop the core and the lua mod. Therefor nothing will really change for them. But the possibility would open for other developers to integrate other languages.

A lot would change. That would require huge internal changes to refactor and modularize the code to support different VMs, and on top of that people would inevitably complain about compatibility issues between the different languages.

Yes the changes would be big but it would allow for testability too. And as long as the language mod author would correctly implemented all of the hooks the whole thing soundly work and if not it wouldn't be your problem anyway as it would be the other mod, that caused issues.

I thing that the core shouldn't really support any VM it should only support hooks for the languages mod to hook up to and leave VM problems to them.

Given how slowly progress has been, even with the community doing most of the development, I don't expect that anyone will be rewriting the mod to support multiple languages any time soon.

CCTweaks has supported changing runtimes (or languages) for a while now, and doing the basics isn't too hard - you just allow people to implement their own ILuaMachine.

However, the catch is rather in the name of the interface: ComputerCraft makes certain assumptions about how the runtime is implemented (such as the presence of coroutines and them being backed by a Java thread) which don't hold up under other Lua implementations, let alone other languages.

It's possible to jump through these hoops but, as you can see, it is far from ideal. A good start would be to come up with a better system of handling events and yielding in a more runtime-agnostic way. However, any such attempt is inevitably going to result in massive breaking changes in the public API, so must be done with caution :).

No :)

You can always make your own language