This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Dynamic Languages on the JVM (and CLR)

Stefan Tilkov,

Ted Neward writes about the need for a dynamic language on top of the VM. I’m sure he’s going to get a lot heat from Ruby and RoR advocates, but I believe he has a point:

If we can get those features we want from languages like Ruby onto a platform that we’ve already standardized on gives us a best-of-both-worlds result. Those developers who are comfortable with statically-typed objects can stay with statically-typed objects. Those who want the more dynamic features of “scripting” languages can do so. We can then blend the two together, to form an interesting and seamless whole: “Give me my Rails, but let me call into a J2EE Connector implementation to talk to the mainframe while we’re at it.” Getting Ruby to run on the JVM or CLR would be a Very Good Thing. It would answer one of the principal criticisms of Rails, for example, that of the idea that it doesn’t do well when dealing with Large Enterprise Things—if Rails could create a javax.transaction.XATransaction before it kicks into ActiveRecord code, for example, suddenly we have a two-phase commit possibility that includes not just databases but mainframes and messaging systems. And yes, people DO need those kinds of Large Enterprise Things in the real world sometimes. Would it not be a win for Ruby to be able to hook into those without having to write all that code themselves?

I agree, although at least as much for political as for technical reasons — which is why I believe JRuby, which has picked up a lot of speed recently, is going to become a Really Cool Thing. Another neat example: RubyCLR used to connect Rails’s ActiveRecord and Windows Forms.