Ask HN: Best Lisp for software development?

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-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.

Everything else, including SBCL, fails a bit short on the overall experience.

In theory you could but your experience won't be optimal.

Everything is packaged together in an UberJar or a Jar. The former can just be dropped on a host and ran, it contains everything needed to run. The latter is meant when packaging a library, it includes only your code, excluding all dependencies. Maven is used for distribution, Maven central and Clojars are the main repositories used for open source.

So there's no issue of compatibility or confusion in how to package and distribute programs or libraries.

But you have the choice between a few different frameworks for writing your build scripts and build pipelines. You can even just roll your own (seriously, rolling your own would take less than a week).

Because of this, there isn't any friction, just choice of multiple ways to define your build steps. So you can choose your favorite style, declarative with Lein, functional with Boot, or Unix-like with tools.deps.

Choice is everywhere in Clojure though, there's always a multitude of options for everything which can most of the time easily be combined together seamlessly and made to work together pretty simply. This choice attracts experienced devs, but turns off lesser experienced devs. It doesn't help that everything always continues to work, as backward compatibility is taken very seriously. So choice can be overwhelming, be prepared for that if you journey in Clojure. You'll have to make decisions of your own, and owe up to them.