The existence proofs for production code for both Clojure and Common Lisp have been done. That is, large teams, large programs, and making money. I'd point you

The existence proofs for production code for both Clojure and Common Lisp have been done. That is, large teams, large programs, and making money. I'd point you towards either one. Both have "modern" toolchains, testing and CI support, etc., depending exactly on what you mean by that. I suggest whatever you pick to spend some time trying out a few different workflows though (some of which may hail from before you were born yet still feel great) rather than deciding something based on what seems "modern" from your past experience. There was a time when Clojure was "just another jar" to sneak into an enterprise Java app and introduce a bit of sanity. It wasn't "modern" then, lein didn't even exist, but it was still worth doing for a lot of people. Similarly there's a lot of CL code out there that just chucks stuff into a single script-like file instead of doing things "the correct" way (the author might even expect you to use e.g. SBCL with the --script flag, which will do something very similar to what Python does when you pass a filename to it instead of launching it on its own), just like a lot of Python code out there chucked into a single file, but it can still be useful and perhaps appropriate for a particular production task. For CL I've recommended this booklet before: https://www.darkchestnut.com/book-common-lisp-application-deployment/ https://www.darkchestnut.com/book-common-lisp-application-de... It helps you quickly get setup into one (of many possible) modern-feeling professional flows (by Java standards at least, which you'll also find following the default lein flow on the Clojure side) with a suggested project layout, a version-pinned library-dependencies definition file, and a single-step source-to-exe process via a simple Makefile that's little more than a wrapper around a simple shell script which would expose functions like all() or clean() as commands. To add a bit more after reading some other replies, it's notable that Common Lisp has multiple implementations to choose from (some open source, some not) and if you're following the ANSI standard (or using various trivial-x or de-facto standard libraries) they can all run your code so you can change implementations rather easily later on if you have a reason to. (There's also an implementation that works well when you need to integrate with C++, and of course a JVM implementation if you do decide you want something in that ecosystem.) Clojure has no standard, it is whatever the on-JVM implementation implements, which has in the past changed and may change again (though the creator has ranted against doing that in general, we'll see if usage of "spec" can continue without changes though) and alter your program's behavior. There's a popular on-JS implementation (if you're looking to write production front-end app code I'd highly recommend getting into ClojureScript over any other Lisp) and a less popular on-.NET implementation, they'll both for the most part run pure Clojure code, but there are a lot of non-portable bits.