Ask HN: Best Lisp for software development?

Racket is good but the toolchain and libraries are far behind Clojure. Especially Cider and Cursive are so great, and for libraries, there are a lot of solid ones like Ring/Compojure, interesting things like Duct, Pathom, Fulcro.

Common Lisp is also good, SBCL/Slime is solid, but it has its own idioms, a multiple paradigm Lisp-2 and feels pretty different from Scheme and Clojure. I found single-paradigm languages like Clojure and Scheme are sufficient to do most things already.

Java-world-wise, you don't have to deal with Java most of the time if you don't want to. There are plenty of Clojure libraries which of course follow Clojure idioms.

Use Graalvm if you want native quick starting binaries or start learning Clojure via ClojureScript

Clojure is the usual go-to for writing production lisp. You should be able to build apps with leiningen, without needing to understand/use and java (except maybe as a runner for your program, if you build uberjars).

Since I build stuff for the web (and Electron, a bit), I use ClojureScript, and am generally really happy with it. It's all the goodness of Clojure — the lispiness, the killer persistent data structures, the wonderfully well thought out standard library — plus the little bit of stuff I like from the JavaScript world — fast boot time, stuff I make can run on the web, good enough debugging/profiling tools, and all the included batteries of the web platform (for audio, video, React if you want it, etc).

I personally use Figwheel to compile my CLJS and do live-reloading, but if I were starting today I'd probably use shadow-cljs. I like to do my own DOM stuff, but if you want to use React I'd do so via re-frame.

You could always try ClojureScript on Node.JS or even ClojureCLR. That said, I have to ask again why the hesitation to rely on the most battle tested most invested in runtime ever built, which is the JVM?

1. More requirements helps. What kinds of production-grade software?

2. For most purposes, you won't see the real benefits, compared to contemporary alternatives, until you have some experience with the Lisp. Enough experience that you realize that, although you can write in a Python or Ruby style in a Lisp, to some degree, there's other various idiomatic programming that's a bigger win sometimes.

3. Once you have some reasonable level of experience, (I'll assert) there's a good chance you become more productive than you would be with a comparable amount of experience in most non-Lisps, in general. But there are some big exceptions to that, such as if you need to do something that can be solved with an off-the-shelf library that's already easily available in Python (e.g., a wealth of ML stuff), for example, and you'd have to write that or an interface for it in your Lisp. Writing it yourself often means you understand it better, and can make it do exactly what you need (including possibly big advantages), but it's an investment.

4. Pick a language and a particular implementation. and make an active user community of that implementation one of the requirements. One of the advantages of Lisps is that they tend to have great communities, perhaps because there's usually little money in it, so you get high-powered people who are there for the merits of it, with a lot less noise. But you do want to find one that's being actively maintained/developed, and that has an active user community.

5. Beware that most development hiring right now seems very driven by fashion, "culture fit", and keywords -- a lot less hiring for "smart, and background they can draw upon to pick up whatever new/other thing is needed". So if you get stereotyped as a "Lisp person", or you don't have one of this year's hot stack keywords on your resume, your next job search might be surprisingly difficult. To a large extent, if you used unfashionable keywords, it doesn't matter if you single-handedly had major accomplishments that would normally be extremely impressive to employers. There are very few Lisp jobs, and there have been very few for a long time. There's a niche for CL, but also a wealth of CL gurus already existing that you have to compete with. There's almost no paying work in Scheme, unless you already have the non-Scheme-specific job and can then pick your tools (i.e, professor, startup, or unusual corporate latitude).[1] If you want to move to a Lisp, but might have to job-hunt in a couple years, Clojure might be the best bet, in that regard, at the moment.

[1] For years, AFAIK, I might've been the world's only consultant specializing in Scheme. But I'm shutting down my business, because there still seem to be only a handful of funded projects using it, outside academia (for university consulting, you need a rare PI and situation, for this to be good) and government (federal subcontractor overhead is a huge burden). Most of the few commercial projects using Scheme are one-person, and don't need anyone else.

(Background: I've done serious production work in Scheme for several years, on some important Web server and cloud technical data science stuff. I also played a very small part in a major project in Common Lisp, using SBCL, and bumped into a bit of CL at another job. And lots of production and research work in C, C++, Java, Python, Perl, etc. separate from that.)

What are you going to achieve by running Lisp in production at your company? How would adopting Lisp improve uptime, performance, meeting feature deadlines, and being able to hire people?

No language is a magic bullet. I would highly recommend focusing on outcomes, such as increased performance or reliability or developer productivity, and picking a popular language to achieve those goals so you can convince management to adopt it, and hire people who are good at it.

If you really, really still want to do it, management will probably be more open to a JVM language like Clojure than to any other Lisp.

But don't try to introduce Lisp into your company, unless you are a cofounder of that company. It's a career limiting move. Instead, work on something you're fond of in Lisp during your off hours.

A bit old now, and Schemes only, but still worth a quick look.

The various web/xml/xpath/database libraries for Common Lisp are well supported by SBCL (or vice versa) and make for a great programming experience for web things, in my opinion.

McCLIM also continues to improve and is an interesting, if not fully ready-for-prime-time, choice for interactive applications.

Clojure + JVM Ecology best fits your requirements.

The ultimate programming methodology, perfect unity and simplicity ---- [The Pure Function Pipeline Data Flow](https://github.com/linpengcheng/PurefunctionPipelineDataflow)

  - be the most modern one
  - have a robust ecosystem
    - package management
    - tooling
  - can be used for building production-ready software
  - be an easy sell to businesses

  - is *the most modern* Lisp that's designed from ground up (no historical baggage/cruft)
  - is hosted on *the Java platform* (i.e., "the Java world"), which is so far the most robust enterprise software ecosystem. This means that you have access to the most robust package management system (Leiningen/Maven), the most battle-tested and production-quality libraries, and the most powerful development tools (e.g., IntelliJ IDEA), and etc.
  - is created by a pragmatic/practical guy who wants to build production-ready software. It's not the result of an academic research/experiment/thesis.
  - is the result of a trade-off that makes it an easier sell to businesses. Businesses tend to be more conservative when it comes to choosing a platform to invest on and usually prefer the ones that are battle-tested, well-established, and well-supported. As of right now, it's the Java platform. No other enterprise software ecosystem can hold a candle to it.

[1] https://en.wikipedia.org/wiki/Clojure#Popularity

For a free CL, SBCL is very good. However it's a very "classic" kind of a language, with just text mode tools and a unix bias.

For a non-CL Lisp-like, Racket is fun, but their debugging story is not my favorite. But pragmatically speaking, Clojure is probably the better choice. It is based in the Java Runtime, so things don't work exactly like they would in a normal Lisp, but in exchange you get great interop with a ton of Java libraries and tools, which I think is a net positive.

That said, Franz ACL would still be my tool of choice, if non-free is not a deal-breaker. :)

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.

The comparison of the need to write C/C++ when using node.js/PHP/python/Ruby is a good one. It almost never happens unless you're doing something very specialized. And better still, the Clojure case is better than many other languages/platforms because via Clojure you can go low-level from Clojure itself (deftype, unsynchronized mutable, etc) without writing any Java code. Again, the cases where you need such low level constructs are very few and far between. Writing your own in-memory data structures comes to mind.