I've switched my own back end codebase to Clojure. It's just a joy to work with. Building REST with Liberator is a revelation. It's so easy to reason about what the code is doing, and immutability leads to far fewer bugs. Not missing objects, not at all.

The stock concern for businesses building with Clojure is the lack of talent and industry acceptance. I have a different angle. I figure that when I'm ready to start hiring other developers, I'll only be hiring developers sophisticated enough to see the benefits of using Clojure over Java/Ruby/Python/etc - and then I'll have the draw of letting them work in the best tools, not making them compromise so it's easier for management to hire less serious programmers.

Been using Clojure in production for our API (core of the system) for close to a year now, it's been a very interesting ride.

Like many others pointed out, I do wish I had types though: refactoring is a giant pain in the ass even at our modest codebase's scale (10-15k lines), requiring endless UTs to make sure everything's still sane. Dynamic typing is fun for the simpler cases, but as soon as you go into trickier computations like crunching analytics data, you continuously run into run-time type mismatches that take forever to correctly pinpoint. Also having to continuously keep in your head just what exactly you're threading through functions is a pain and requires a lot of mental overhead.

The JVM also doesn't seem to bring much of a benefit to the table, considering that we only ever deploy onto 64bit Ubuntu 12.04, so there's not really a big need for portability.

The best part has been how fun it is to work in clojure and the community around #clojure channel with so many of its freakishly smart people. People on there seem to generally be very willing to help explain something if you're being obtuse.

We've been using Clojure for our web app at work since day 1. The biggest gain by far is the referential transparency[1] built into the core libraries, which has also been closely adhered to by nearly all third party libraries (with only a few unfortunate outliers). I cannot emphasize enough just how much of a gain this has been.

[1]: http://en.wikipedia.org/wiki/Referential_transparency_(compu...

Not sure if I like the 'some?' operation. It's short for (not (nil? x)).. And has nothing to do with 'every?' -which checks if every element of a collection matches a predicate - ex (every? odd? [1 3 5])

To check if some elements match you need to use (some odd? [2 3 4]) - note the lack of '?'

Bet it will confuse people.

Absolutely loving Clojure. I typically hang out in java-land. I tested it out on an annoying problem to scratch an itch and wow, I'm actually enjoying programming again. I find myself looking forward to solving problems with Clojure in a way I haven't for a long time.

Some of the smartest code I've read lately has come from the Clojure community. It's a great time to live in NYC.

Like many people on the mailing list, I've been using the Clojure 1.6 betas and release candidates. Don't expect dazzling new features; rather, 1.6 is a nice solid step forward.

A nice pragmatic Lisp, might never use it at work, but it sure is fun to play with.

Congratulations on the work.

Nice upgrade. I have used Clojure for several customer projects and some of my own little projects like cookingspace.com and my-foc.us

Clojure is a very practical language and basically stays out of your way during development.

A healthy language ecosystem on the JVM is a good thing, glad to see a new Clojure release.

I plan to learn Clojure this year. What online resources and books can you recommend for learning the language and the tooling?

Does anyone know where the Clojure roadmap is? I'm wondering what I can expect in the next big release :)

Congrats on the release!

like the emacs org-mode pprint support. especially the example output claiming the well deserved rock star status.

It's always hard get a sense of the actual usage presence of Clojure when I spend so much time on HN, where Clojure is disproportionately represented.