Clojure is a LISP-style language for the JVM. One focus of Clojure is concurrency, which it supports with its immutable its data structures (Clojure comes with persistent data structures). Another feature is Software Transactional Memory (STM), which allows to use transactions, instead of Locks or Mutexes, to update shared memory. While STM is a controversial technology that still needs to prove itself, having access to an implementation on the JVM offers an easy way to experiment with it.

Particularly interesting in this regard are Clojure's Persistent Data Structures, for instance its Persistent Vectors. Note: In this context, the word "persistent" doesn't refer to data being persisted to disk. Persisted Data Structures are immutable; modifications, like insertions, are possible but they always yield a new "copy" of the full data structure. Clojure's implementation and the immutability constraint allow to avoid having to do a full deep copy; instead, only a relatively small delta has to be copied. Karl Krukow shows the implementation of Clojure's Persistent Vector, and explains how it achieves its performance behavior.

Another opportunity for JRuby developers is Clojure's STM support, which is offers a way for Ruby developers to experiment with this concept. Even if the Ruby code doesn't explcitly use any particular Clojure STM features, it's still possible to write the underlying application model in Clojure, and have JRuby for the fronted part, be it from Rails or other Ruby frameworks.

Another option is to use Clojure for performance bottlenecks. While JRuby's performance is steadily improving, there are still situations where it'd be nice to exchange (J)Ruby's polymorphmism and flexibility for performance. In MRI, performance bottlenecks in a Ruby application can be fixed by writing a native extension. In JRuby, one solution is to write code in Java, be it Java source code or a way to generate JVM bytecode (either bytecode generation with a Ruby bytecode DSL or a language like Charles Nutters' Duby).
Choosing a lower level, system language, be it C (for MRI) or Java (for JRuby) has an obvious downside: dropping down to the level of Java and losing features such as Blocks, many types of metaprogramming, etc.
Clojure is a possible solution for this problem: the language has various levels of flexbility. For instance, normal Clojure functions have low call overhead as they're mostly reduced to static method calls. Clojure does offer different styles of runtime polymorphism, for instance in the form of multimethods.

Clojure is a LISP and comes with a powerful macro system. Macros allow compile time metaprogramming, which brings even more opportunities to offload code generation to the computer (instead of writing boilerplate or repetitive code in Java by hand). Clojure code is always compiled to JVM bytecode, Ahead Of Time (AOT) compilation is also supported. Azul's Cliff Click took a closer look at the performance of some JVM languages, including Clojure and JRuby and provides some information about Clojure's performance. All in all, Clojure offers a lot of opportunities to write fast code in an elegant style.

The other side of the medal is of course a matter of dependencies: using Clojure means another new dependency to a project. Whether it's a good idea to add another, still little known, language like Clojure to a project, is a question every team has to answer.
The STM solution to concurrency and shared data has been widely debated. Clojure creator Rich Hickey had a long discussion with Azul's Cliff Click on the topic of STM. Another source of information about STM is last September's ACMQueue issue on Concurrency.

Clojure libraries inspired by Ruby libraries are one way the two languages interact.

You could really say that about any language.

the two languages share the same underlying runtime, the JVM.

Fine, but you can say that about any language that shares a common runtime.

Frankly, I think there's a big problem in the JVM ecosystem as Java (the language) goes into maintenance mode. Clojure is cool, has some great concepts, and Rich Hickey is a really bright guy, but s-expressions are just too weird for your average business IT department. Both JRuby and Clojure are dynamically typed, which is a problem in your average IT department. Plus almost all language research is going in the ML/Haskell like direction.

Boo is coming to the JVM, and despite being pretty obscure on dotnet, and not even out on the JVM yet, it has many powerful features (static/dynamic typing, macros, very readable). I think it's a better fit than either Clojure or JRuby for your average Java developer.

I agree that Boo is a very exciting prospect for the JVM. I'm glad to see we're wooing new language developers back to the ride side of the tracks :) If Boo comes to the JVM I may not need to finish Duby (or I may be able to back Duby with Boo's toolchain). Really cool stuff.

And Boo or Scala may be better fits for the "average" Java developers than any dynamic language, but dynamic languages like JRuby or Clojure or Groovy are the right fit for a lot of problems Java developers struggle with. The JRuby+Clojure mashup is more evidence that the JVM, being a result multi-language VM, allows you to use whatever tools you think fit your problem best. For Daniel, JRuby+Clojure is one such combination of tools.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.