The fact that Clojure runs on JVM turns me off. I find that Elixir is very similar to Coljure, with a runtime that better supports immutability and concurrency.
If you can use a runtime with gazillions of man-hours invested into making it better, and get easy access to bazillions of native libraries, why not?
Note that this same comment argues for Electron.
> a runtime with gazillions of man-hours invested into making it better,
"Man-hours" are such a non-measure of productivity that the classic software engineering book in our industry has a title that declares them a "myth".
The JVM turns out to work fine for functional languages like Clojure, but from my perspective, there's no inherent reason it necessarily should. There's a huge impedance mismatch, as Clojure is not much like Java, and the priorities are completely different.
Bragging that some C program has had a gazillion people work on it means either it has a gazillion special cases (not an advantage), or it has a gazillion bugs fixed (most of which were probably caused by using a low-level unsafe language like C in the first place). Yay but ouch.
(Implementing a new programming language is also typically a vast and complex task, but Clojure has an impressively small number of contributors. When you think through the design first and focus on simplicity, you don't need a gazillion special cases.)
Coming from the Common Lisp world, there's gobs of pure-Lisp programs and libraries I've used which are absolutely a joy to work with, at every level. They don't need many contributors because the code is drastically shorter and simpler. There's lots of Lisp libraries with only a dozen commits, which haven't been touched in years, and a version number way less than 1.0, which work great. That's all they need.
> and get easy access to bazillions of native libraries,
I can see why these can be important when bootstrapping a new language environment, but in practice, beyond version 1.0, I really don't care about them at all. The interfaces I use from Clojure tend to be "return a function", or even "return a function which returns a function". No Java library is designed like this. They're designed around mutable classes, which makes them pretty awkward to use from a functional language. I'll go find a 100-line native Clojure library instead, and by now, there's 100-line native Clojure libraries for almost everything I need.
For another example, the numeric tower is part of the core of Common Lisp, so it's usable from anywhere. BigInteger is a library in Java, and Java still doesn't seem to have rational or complex types, so Clojure does the best it can, but anything beyond fixnum arithmetic is basically opt-in, and almost no libraries use it.
Debugging is even worse, because while there are a million google hits for "java library X", and a thousand hits for "lisp library Y", there's often almost no hits for "java library X with clojure". I have to mentally translate the Java X solutions into Clojure, and figure out any JVM/Clojure interop issues myself from first principles.
That said, Clojure overall works great in practice, and for the most part you can ignore the JVM and its issues. But any time I'm forced to become aware that the JVM exists, my life ends up being worse than the equivalent scenario in the turtles-all-the-way-down world of other Lisps.
You mentioned Common Lisp: it's a good example. I found bugs and limitations in CL runtimes and was several times in a situation where it was clear that I was the "only user". I do not want to be in that situation.
BTW, CL people often say that one should get a paid Lisp because of support. I did (AllegroCL) — and Franz people were really nice, but couldn't find the problem, and I couldn't dedicate the time to hunting it down and providing debugging information. Support doesn't mean that your bugs get fixed.
The JVM is not perfect, but its usage scale matters and means that in general, you are not likely to hit a JVM bug.
Additionally, there's a CLR version of Clojure as well [0] and I'm surprised that doesn't pop up very frequently. It seems to have a fairly active community around it as well [1]. I haven't looked into it yet, but I intend to once I'm more familiar with the JVM version.
[0] https://github.com/clojure/clojure-clr [1] https://groups.google.com/forum/#!forum/clojure-clr
That said, some do, and the maintainers are active, so I'm sure it works well if you had reason too.
There are alternative methodologies and languages that are similar to BEAM and Clojure otoh. Perhaps not comparable to BEAM when it comes to concurrency. Racket + ZeroMQ for those kind of problems, immutability and concurrency, is a very interesting combo though.
Sidenote: You could run on Javascript runtimes with ClojureScript, but given your statement, I don't believe that is interesting to you :)
(My perspective: I am turned off by any language that doesn't have a JVM implementation because I have so much knowledge and trust of that runtime. But I have to acknowledge, byte-code level support for immutability is thin to non-existent).
As for the JVM, I would be curious to know why it's a turn off. It has been worked on for decades and powers mission critical systems everywhere. Unless you are doing something where the size of the VM matters, or where GC as implemented in the JVM is a non-starter I'm not sure why it matters.