You're not alone with regard to Ruby. I was lucky enough to start using Clojure pre-1.0 at work. I come from a background where I've done a lot of functional programming. With Clojure, it was a joy to finally use a Lisp with well-designed conventions that I could actually get things done with.
However, I've since moved on to Ruby and learned a lot about its metaprogramming features. This is purely my opinion, but I get the impression that a lot of people who are smart enough to get Lisp, functional programming, and metaprogramming dismiss Ruby as being yet another OO language too soon, before getting to know it. On the contrary, I've found that the more I learn about Ruby, the more it grows on me, and the more similarities I see it has with Lisp.
I guess what I'm saying is, the reason I use Ruby is kind of like the reason I use a Mac, or why I tend to use languages with dynamic typing. There's no one killer feature that I can point to over the competition. In fact, there are a number of features that are hands-down superior in the other. I haven't quite figured out how to explain it to people coming from the other side, but for me, Ruby just hits the sweet-spot on so many levels. People talk about Macs being usable and even loved by grammas who know nothing about computers and hackers at the same time, audiences on complete opposite ends of the spectrum. Ruby is similar. On the one extreme, it's approachable to complete newbs. I know designers who would turn their nose up at the sight of code but were willing to learn the basics of Ruby to implement their designs. On the opposite extreme, it supports first-class continuations out of the box, which isn't even part of the Common Lisp standard. Also, a lot of times when I would've needed a macro in Lisp, I simply didn't in Ruby. And that's hard to explain... Sure I can do things with macros in Lisp that I can't in Ruby, but all other things being equal, wouldn't you choose the non-macro way over the macro way? (Sigh... I hear the flames starting.)
I'm not sure I agree with you about state, but it's true that with a web server and db, I've so rarely ever needed more concurrency features. Maybe this means Clojure is just not meant for people like me writing mostly web apps. But to play devil's advocate, maybe it's a good thing to let a piece of software designed specifically for handling concurrency -- handle the concurrency. Namely, a web server or database. This actually forces me in a good way to design my app up front to do any heavy processing asynchronously outside of a web request, which often means a queue, which often implies work divided into small pieces run concurrently by workers (separate processes, possibly on remote hardware, not just using an agent in another thread or relying on shared memory) which may die at any time without significant effect (a la Erlang). ...Again, maybe I'm just not in Clojure's target audience.
I use Ruby at work, I like Ruby and I like its metaprogramming facilities. However Ruby's features just doesn't cut the mustard when you want to build something like this, https://github.com/clojure/core.logic. I'm also working on implementing a fast state-of-the-art pattern matcher a la OCaml, https://github.com/swannodette/match.
These aren't small metaprogramming things - these are considerable useful language features reachable in Clojure that are not reachable with acceptable performance in the current crop of mainstream dynamic programming languages.
Fair enough. But if you want to start citing examples, I could say the same about Clojure. As far as I know, without JVM changes there's no way in Clojure to implement conditions and restarts in a way that allows you to handle thrown exceptions from code that doesn't know about conditions. OTOH this is just a library in Ruby. https://github.com/quix/cond
I don't want to get academic/knit-picky. I guess my point is even though living on the JVM definitely has some big advantages, it also has some drawbacks.
I'm not trying to knock Clojure. I think it's great. But this thread is about why you're not using it. So I'm just speaking to that.
[Edited to talk less about Ruby and more about Clojure.]
Admittedly this doesn't violate your general point; there are things like continuations that are hard to do with Clojure due to limitations the JVM. However, I tend to find there aren't many things Clojure can't do, and in general it seems more flexible and better designed than Ruby.
However, I've since moved on to Ruby and learned a lot about its metaprogramming features. This is purely my opinion, but I get the impression that a lot of people who are smart enough to get Lisp, functional programming, and metaprogramming dismiss Ruby as being yet another OO language too soon, before getting to know it. On the contrary, I've found that the more I learn about Ruby, the more it grows on me, and the more similarities I see it has with Lisp.
I guess what I'm saying is, the reason I use Ruby is kind of like the reason I use a Mac, or why I tend to use languages with dynamic typing. There's no one killer feature that I can point to over the competition. In fact, there are a number of features that are hands-down superior in the other. I haven't quite figured out how to explain it to people coming from the other side, but for me, Ruby just hits the sweet-spot on so many levels. People talk about Macs being usable and even loved by grammas who know nothing about computers and hackers at the same time, audiences on complete opposite ends of the spectrum. Ruby is similar. On the one extreme, it's approachable to complete newbs. I know designers who would turn their nose up at the sight of code but were willing to learn the basics of Ruby to implement their designs. On the opposite extreme, it supports first-class continuations out of the box, which isn't even part of the Common Lisp standard. Also, a lot of times when I would've needed a macro in Lisp, I simply didn't in Ruby. And that's hard to explain... Sure I can do things with macros in Lisp that I can't in Ruby, but all other things being equal, wouldn't you choose the non-macro way over the macro way? (Sigh... I hear the flames starting.)
I'm not sure I agree with you about state, but it's true that with a web server and db, I've so rarely ever needed more concurrency features. Maybe this means Clojure is just not meant for people like me writing mostly web apps. But to play devil's advocate, maybe it's a good thing to let a piece of software designed specifically for handling concurrency -- handle the concurrency. Namely, a web server or database. This actually forces me in a good way to design my app up front to do any heavy processing asynchronously outside of a web request, which often means a queue, which often implies work divided into small pieces run concurrently by workers (separate processes, possibly on remote hardware, not just using an agent in another thread or relying on shared memory) which may die at any time without significant effect (a la Erlang). ...Again, maybe I'm just not in Clojure's target audience.