Just got email from Erin (hint, Erin, you need a blog (here is a pretty one to spur your imagination)):

Contract is signed. We're officially "Professional Ruby Developers". :)

Chariot has its first (primarily) Ruby (on Rails) gig!

So, let's see, nothing like an interactive session log to show things:

brianm@kite:~/src/ttmp$ irb 
irb(main):001:0> require 'ttmp'
=> true
irb(main):002:0> t = TTMP::Connection.open "brian", "wombats", "localhost"
=> #>
irb(main):003:0> t.on_receive { |m| puts ">> #{m.body}" }
=> #
irb(main):004:0> t.subscribe "a"
=> nil
irb(main):005:0> t.begin 
=> nil
irb(main):006:0> t.send "a", "hello queue a"
=> nil
irb(main):007:0> t.send "a", <<-EOM
irb(main):008:0" Longer message to queue a..
irb(main):009:0" 
irb(main):010:0" lalala =)
irb(main):011:0" EOM
=> nil
irb(main):012:0> t.commit
=> nil
irb(main):013:0> >> hello queue a
>> Longer message to queue a..

lalala =) 

Hmm, that is nifty. So what though? Well, this will work transparently between ruby and Java (via the JMS API) -- right now just on the most performant and easiest to use open source JMS implementation around (just my opinion) -- but with just a couple hours work, any JMS implementation.

I was going to wait to post much more about this until I'd had a chance to push together Perl, Python, PHP, Bash, PLT Scheme, and maybe an SBCL implementation of the client -- but comments on the TSS kinda pushed me over the edge, so I'll just post now =)

The TTMP protocol has changed some since my last post, but the basics are the same. It will be changing some more, but a solid 1.0 protocol spec should be available after this coming weekend (unless I have too much fun up in NYC with Patrick). The implementation for ActiveMQ is in subversion now and should be available with the upcoming 3.1 release -- you are welcome to grab the snapshots, or build one to play. Once I am happy I'll put a tarball up with a default ttmp handler, alongside a default optimized binary (for the Java and C# clients).

Ruby client source.

Ruby isn't the threat to Java, vendors jockying for advantage at the expense of their users in the standards game is the threat to Java. I wholly agree with Jason that Java is being disrupted though.

Ruby is a fantastic language, but not one which will "supplant" Java (I still believe that whatever the next dominant language is, it will look and smell like Scala). I have a sneaking suspicion that language diversity is picking up. Sure, something will dominate like Java, C++, Fortran, Pascal, COBOL, etc have -- but for a while there won't be. Ruby is one option -- it has been my preferred language for a few years -- and I use it where I can and where it is appropriate. That is actually more and less places that might be thought. I cannot think of the last significant Java project I have worked on which didn't have at least some one-off ruby code generators, for instance. Will I stop writing Java? Heck no -- I like Java, for all its foibles and flaws (just as I do Ruby, for all its foibles and flaws). Pick the best technology for the job -- sometimes that is even Scheme (which I used most heavily when my primary role was systems admin stuff, go figure) =)