Aware it's bad form to reply twice, but here's a separate post about what I dislike in Clojure from an honest perspective and mostly what I feel the community w

Aware it's bad form to reply twice, but here's a separate post about what I dislike in Clojure from an honest perspective and mostly what I feel the community would agree: * It's on the JVM (good and bad). JVM is boring, JVM loves crazy config and Java libraries. JVM has legacy baggage. JVM has garbage collection which precludes Clojure from some problem domains or otherwise handicaps it (game dev, real-time) somewhat. The list goes on. * Core.Async is great, but parts of it can't really be optimized because of the JVM, once again. Go does a better job supporting some of the same constructs at a lower level. Counter-point: I am light years more productive in Clojure than Go because of functional programming, immutability by default, and better/more libraries for my purposes given the entire JVM ecosystem. * Macro Debugging. Yeah, there's not much getting around this, but I mentioned some tips in my other post. * AOT. It's there if you need it but it's less than thrilling to work with. * Multiple versions of Clojure in the same JVM. People are working on it, but it's an issue caused by the JVM once again. Anyone who has used Storm has probably hit this at least once. * Editors. There's Emacs and IntelliJ/Cursive, but the rest of the pack of popular editors have questionable or more limited support. Fireplace + Vim is decent too. A good example I saw recently was someone was lacking good, bug-free Clojure support thus far in VSCode. This is mostly due to community size. * Community size. It causes a lot of things. On the plus, the community is more friendly, open, and accessible at all levels. There's no layers between people very much or hierarchy. On the negative side, there is less output because of it, though I feel sometimes this helps with quality control. Ability to use Java libs helps here. * Null/Nil/Exceptions. I agree with how Rich gave treatment to nil, but I mention it because a lot of people hate it, especially with some ops that return nil. If you are a monad person, this will start to get to you. Exceptions also bubble up sometimes and mess with your beautiful functional compositions because of Java underpinnings. * Functional purity. I worked in various Lisps, Haskell, and others. I don't buy this argument, but some people would rather burn themselves alive than use an impure pestilence like Clojure. * Graphics Programming. I mean you have Java and some Clojure GPU libraries, but it's kind of weak. This applies to most languages that aren't C or C++ though. * Certain domains. I mentioned graphics, I'll also again mention real-time and games. I don't think you should be writing the next Mars Lander in Clojure. * Garbage. Again, JVM, but it's worth stressing that Clojure generates even more garbage than normal in some cases. You can avoid this if you really care and can shortcut some things by making use of transients. * Performance. Transients also will help here. Clojure performance is pretty good, but it's not Rust or C good. Like any language, you need to understand where the costs accrue with productivity. * Legacy core or widely-used libraries. Some of these suck or have some design issues. I personally don't like zipper for example and use 3rd party stuff if I want the same thing. Core.typed for awhile was bothering me too. * Startup time. It sucks. It's getting better, but it is a hard thing to make progress on. Pixie is one alternative if you want something similar in another language, though I'd personally either stick with Clojure or pick a different language if that was important to my app. Example: not the best thing in the world for shell scripting. * Pre-existing knowledge. It's not a requirement, but it certainly helps to have other languages under your belt first. Knowing Java and the JVM really helps, especially with debugging if you are that lost. * Lein/Maven. It's getting better, there are alternatives (boot), and these tools are pretty awesome compared to most (looking at you Go and also Nodejs). Still, there's some rough parts here carried over from maven. For instance, "lein clean" is a thing. * Size. Heaven help you if you want tiny output of a binary/package (ex: JAR). But then again, you're using the JVM so I assume you didn't believe in such things. * Lack of tail optimizations. JVM issue again. Clojure works around it, but it would be nice to have had at the start. This angers Lisp purists. * Namespace issues. Mostly just about blowing up REPL state. Namespacing is actually pretty good, it just has some limitations in the Lisp sense. * What is broken by design to some degree will be at best patched, not fixed. Rich has stated numerous times he doesn't want to entirely break peoples code, but he will try to patch things. A good example is transducers were an improvement, patch, and built in a way that didn't break existing stuff. This means though some of the rough parts are here to stay. There's many more, but that's my honest perspective for you. I would never pick 1 language for all projects or even most of my projects. Use the best tool for the job. Clojure sometimes is it for me, hopefully for you too. Good luck.