> * poor ecosystem of libraries - few gems, most other half-baked Specific to common lisp: I don't find the ecosystem to be poor but I notice that many are tur

> * poor ecosystem of libraries - few gems, most other half-baked Specific to common lisp: I don't find the ecosystem to be poor but I notice that many are turned off by the look and feel of library landing pages which do feel dated. In same cases I have felt the libraries lacked documentation, like Caveman2, but in the end I found there was little to document after reading some of the source code. Specific to Clojure: I don't think this criticism applies to Clojure at all and the popular Clojure libraries usually come with great documentation as well. IMO, JavaScript is also littered with mounds of crappy half baked libraries as well but people still use it for server side stuff even though they have a choice to use something else. > * poor community coordination Which lisp community? > * Dependency management limitations with quicklisp What limitations? Also, if you don't like quicklisp or common lisp in general, I think Clojure really nails dependency management and find it very easy to use. > * poor support for json[6] Specific to CL: I can understand this because there are a number of libraries and no obvious winner. JSON isn't the only data serialization format though. Guess it depends on what you need. https://www.cliki.net/serialization https://www.cliki.net/serialization > * poor support for async Specific to Common Lisp: There is cl-libuv: https://quickref.common-lisp.net/cl-libuv.html https://quickref.common-lisp.net/cl-libuv.html and wookie. Specific to Clojure: core.async is great and if you don't like it you are also free to use node.js as your runtime with clojurescript. > * have to restart the server every 20 days because of some memory leak [3] If I had a dollar for every node.js production app that suffered this very same problem I could probably retire today. I thought it was interesting that the author of that article says the service was re-written in node.js given node.js is hardly immune to these sorts of problems. IMO, async is just a pain to work with and these types of issues are a manifestation of that. > * hack to tune GC [5] Users in JVM land also report having to resort to tuning the GC or selecting the optimal GC for their use case. I don't think this is a reason to shy away from lisp. > If you are using lisp in production for non-trivial cases, do these issues still exist? I have not personally encountered these issues in Clojure or CL. That is not to say they do not exist. But they also exist in plenty of other popular platforms to varying degrees. See my responses above for examples. > and, finally, if you had to re-do your project, would you chose lisp or something else? I would still choose lisp, either Clojure or Common Lisp. I generally favor Clojure to CL.