[anonjon]

It is hard to describe in a HN post why Clojure is a good idea.

Easy concurrency is a reason, certainly. You can build applications without having to worry too much about locks and such. You can utilize in language data structures for concurrency rather than worrying about a database handle (if you have, for example, data you don't need in a database, there is no reason to use one...)

Functional programming is another reason, programs are easier to reason about if you limit state to a few key places in the program.

Macros are a good reason too, instead of working around deficiencies in a language, just implement a macro. I used erlang Jinterface to implement an erlang-style message passing library last weekend. (With process spawning semantics and blocking receive, I haven't done pattern matching.. yet).

Java libraries are another reason to use it. You have full access to Java libraries like Jetty and Jinterface and others, and they pretty much blend into the language.

I have no idea about the relative merits of Ruby and do not wish to offer my reply as a challenge; 'i bet it can't do this or that'.

But Clojure certainly offers some interesting solutions to common problems in code (verbosity, clarity, libraries, concurrency, reliability).

[Slashed]

I'm not very familiar with Clojure. On the first glance it looks like Clojure has a good concurrency system. I know many people are talking about Actors(like in Erlang) these days, but from my experience with Scala Actors, they're not very suitable to solve some problems(like when you need a very good performance). Even though Scala makes your life easier to work with native Java concurrency, it's definitely a good reason to have a deeper look at Clojure. Thanks for the info!

Edit: Is there an 'easy' way to create OSGi bundles with Clojure, maybe some sort of Maven plugin?

[tmountain]

Clojure has a few different concurrency mechanisms. Agents are useful for asynchronous manipulation of mutable state while refs allow for coordinated synchronous changes. Atoms allow uncoordinated synchronous access to state while vars act as mutable storage locations on a per thread basis.

Between these, you get four different strategies for dealing with concurrency. Depending on your problem, you can choose the most efficient mechanism. Rather than shoehorning you into a particular strategy, Clojure gives a you a toolbox for dealing with concurrency and lets you chose what makes the most sense.

[dkersten]

You forgot one: if, for some reason, none of the four mentioned concurrency strategies suit your needs, you can fall back to Javas monitor-based threading model. I don't see why one would want to, but I'm sure there are situations when this actually is the most appropriate mechanism.

[tayssir]

And a possible future feature is something like statically-checked locking, where order-of-acquisition issues are dealt with.

[mike_organon]

Actors for Clojure has been mentioned as a future feature, but this would be for remote procs. Clojure has Agents for local async state changes, but these are only used when you need that feature, not ubiquitously. You should ask on on the mailing list - people have worked with osgi and maven.