One issue with Clojure is that it comes with strong opinions (STM, immutable data structures, JVM-Java ecosystem) and thus is not as paradigm-enclosing as other Lisps (e.g. Common Lisp).
I'd much rather have SBCL's native code compiler, read/compiler macros, conditions and restarts (that I end up using on pretty much every project) and optionally use libraries for immutability and STM (if and when I need them), than compromise from the get-go and use a language that reduces the set of available options by forcing its specific worldview.
If I do need a strong focus on concurrency, I find Erlang (and also Elixir) a much more coherent solution. The cognitive dissonance that comes from having to interact with Java when using Clojure is very damaging and it can't be abstracted away. Just look at Clojure stack traces.
So to end with, Clojure proponents should understand its limitations and design choices. It was created because Hickey needed a language to solve problems he was having in his specific arena (delivering concurrent applications in the Java ecosystem with his consultancy) and not really to improve on the Lisp state-of-the-art side of things. If you're a Java guy and absolutely need to stay in that ecosystem, I guess you can go with it. Otherwise, you end up giving away too many things. This has been validated in practice, in the Common Lisp community. We get a lot of guys who are coming _from_ Clojure, but it is rare for someone to move _to_ Clojure from CL.
> It was created because Hickey needed a language to solve problems he was having in his specific arena (delivering concurrent applications in the Java ecosystem with his consultancy) and not really to improve on the Lisp state-of-the-art side of things.
It's true that Clojure isn't trying to be SBCL, but you're mischaracterising what Clojure is designed to do.
Clojure is based around the idea that good code minimises interconnections. In Clojure parlance, "complex" code is code that is very interconnected, and "simple" code has few interconnections. Clojure is designed to make it easy to write "simple" code.
CL programmers tend to look at Clojure and say "Why should I use Clojure when CL is more powerful?", but Clojure isn't trying to be more powerful than SBCL, because sometimes adding power means sacrificing simplicity.
Clojure is an insufficient CL, but CL is an insufficient Clojure.
> The cognitive dissonance that comes from having to interact with Java when using Clojure is very damaging and it can't be abstracted away. Just look at Clojure stack traces.
This is what has kept me from really feeling comfortable getting into Clojure. Unfortunately there are so many downsides in the Functional programming world :( It's either:
1. Have a strange interrop (Clojure with Java, and even though Elixir with Erlang isn't as bad, it still bothers me)
2. Lack of mainstream adoption (e.g. Haskell, yes FB uses it for their spam filters.. but mostly working developers predominantly use other languages)
3. Lack of clear tooling choices or implementations (Haskell's stack vs. platform, or Scheme is great but no one popular implementation)
> The cognitive dissonance that comes from having to interact with Java when using Clojure is very damaging
I don't use Clojure, but isn't relatively seamless Java interop -- and thus access to the massive Java ecosystem -- considered one of the big pragmatic advantages?
> Just look at Clojure stack traces
There are prettifiers that clean this up, but I understand your complaint is cognitive dissonance. The Java guts are right there, and I guess this is the heart of that matter. Some don't like chocolate in their peanut butter.
I really tried SBCL, but even knowing a little Lisp (own about 6 books I've read most of), I couldn't get past the tooling. SLIME+emacs is powerful, but the tutorials are awful and very lacking. Sadly, Clojure isn't much better here. Racket is pretty good here, but I can't get past the fact that I'm essentially playing with an educational product and not a real industrial language.
That is not true. It is a vital part of the language. It is not often talked about because its not 'flashy' anymore. If you want to keep some data in a safe way you have a easy language tool to do that for you. There are also more advanced usages. People use it, and it works.
I think Agents are more on the way out because of core.async.
I'd much rather have SBCL's native code compiler, read/compiler macros, conditions and restarts (that I end up using on pretty much every project) and optionally use libraries for immutability and STM (if and when I need them), than compromise from the get-go and use a language that reduces the set of available options by forcing its specific worldview.
If I do need a strong focus on concurrency, I find Erlang (and also Elixir) a much more coherent solution. The cognitive dissonance that comes from having to interact with Java when using Clojure is very damaging and it can't be abstracted away. Just look at Clojure stack traces.
So to end with, Clojure proponents should understand its limitations and design choices. It was created because Hickey needed a language to solve problems he was having in his specific arena (delivering concurrent applications in the Java ecosystem with his consultancy) and not really to improve on the Lisp state-of-the-art side of things. If you're a Java guy and absolutely need to stay in that ecosystem, I guess you can go with it. Otherwise, you end up giving away too many things. This has been validated in practice, in the Common Lisp community. We get a lot of guys who are coming _from_ Clojure, but it is rare for someone to move _to_ Clojure from CL.