Wednesday, August 26, 2009

Introducing Surinx

In June of this year, I spent a few hours formulating a dynamic cousin to Duby. Duby, if you don't remember, is a static-typed language with Ruby's syntax and Java's type system. Duby supports all Ruby's literals, uses local type inference (only argument types *must* be declared), and runs as fast as Java (because it produces nearly identical bytecode). But with the advent of invokedynamic, Duby needed a playmate.

Enter "Juby". Juby is intended to be basically like Duby, in that it uses Java's types and Ruby's syntax. But it takes advantage of the new invokedynamic opcode to be 100% dynamic. Juby is a dynamic Duby, or perhaps a dynamic Java with Ruby syntax. It's not hard to comprehend.

But the name was a problem. Juby sounds like "Jewbie", a pejorative term for a Jewish person. So I sent out a call for names to the Twitterverse, ultimately ending up with far more names than I could choose from.

The name I have chosen, Surinx, has a simple story attached. You see, when James Gosling created Java, he originally named it "Oak", after the tree outside his window. So I followed his lead; the tree (a bush, really) outside my window is a lilac, Syringa vulgaris. The genus "Syringa" is derived from New Latin, based on a Greek word "surinx" meaning "shepherd's pipe" from the use of the Syringa plant's hollow stems to make pipes. Perhaps Surinx is building on the "hollow stem" of the JVM to produce something you can smoke (other dynamic languages) with. Combined with its cousin "Duby", we have quite a pair.

And in other news, the simple Surinx implementation of "fib" below (identical to Ruby) manages to run fib(40) in only 7 seconds on current MLVM (OpenJDK7 + invokedynamic and other tidbits), a five-fold improvement over JRuby's fastest mode (jruby --fast).

def fib(a)
if a < 2
a
else
fib(a - 1) + fib(a - 2)
end
end

Given that JRuby has started to support invokedynamic, the solid performance of Surinx bodes very well for JRuby's future.

Please welcome Surinx to your language repertoire!

Sunday, August 2, 2009

Which Deployment for JRuby on Rails?

We often get the question "which deployment option is the best for JRuby on Rails?" The truth is that it depends on what you need out of deployment.

If you have a fairly straightforward Rails app without a lot of service dependencies and a greenfield deployment target, your best bet is probably the GlassFish gem right now. It performs really well, can handle high loads and high concurrency, and automatically detects Rails' threadsafe mode, scaling better when it's turned on. I'm no longer a Sun employee, and I still think the GF gem is an outstanding piece of work. Here's my howto on GF gem + JRuby on Rails + Apache. Update: Here's information on using Capistrano with the GlassFish gem.

If you have an existing Java EE or web container like Tomcat, JBoss, GlassFish, WebLogic, or WebSphere, you want to look into Warbler. Warbler packages your application as a .war file, suitable for deployment on any of these standard servers. The Warbler wiki is the best place to learn about deploying with Warbler.

If you're looking for something that's somewhat greenfield but also needs more advanced services like scheduled asynchronous jobs, web services, and some level of EE integration, you should look at JBoss's TorqueBox, a customized JBoss specially tailored for deployment of Rack-based apps (like Rails) on JRuby.

If you're looking for a hosting provider that can take your app and make it "just work", then you should look into Engine Yard's JRuby cloud offering. We don't yet have it 100% ready to go, but it won't be long and it will be fantastic. For now you can give us some direction and input on what that hosting/cloud should look like.

All told, there's a lot of great options for JRuby deployment, and no one of them is going to be perfect for everyone. Choose wisely, and join the JRuby mailing lists if you have questions.