
Ask HN: Best Lisp for software development? - foobar123321
Hi HNers, I&#x27;ve built a lot of software in Python and Ruby over the years and recently, I&#x27;ve become interested in Lisp but am unsure which Lisp&#x2F;Scheme variant to learn for building production grade software.<p>Ideally, I would like to learn the most modern one i.e. robust package management, tooling, ecosystem, etc. Really the main requirement is that I would like to be able to build production ready software with a Lisp that I can use at and for my company.<p>I&#x27;ve looked into Clojure and like a lot about it, but don&#x27;t want to have to dig into the Java world. Is there any alternative out there? Any suggestions are appreciated :)
======
namelosw
My personal choice would be Clojure. I learned Racket and Common Lisp but
haven't used them build something production-grade yet. I don't even know how
to properly build, deploy and monitor a Racket server yet.

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.

~~~
traderjane
Am I wrong for saying that the Clojure community has not yet achieved
consensus for things as simple as a build system? In some ways that seems like
there would be more up-and-going friction than the JS build world.

~~~
msbarnett
Doesn’t JS have basically the exact same thing going as leiningen vs boot in
npm vs yarn?

~~~
uncletaco
Not really no. Lein and boot don't read from the same project declaration file
and clj adds another way to declare dependencies through dep.edn files. A
previous poster was being _very_ optimistic when they said you could switch
from one to another in fifteen minutes.

On the other hand using yarn or npm is almost completely interchangeable for
the vast majority of workflows. The only thing one should be careful about
with regards to them are project lock files. Otherwise most of the user facing
differences are more about form rather than functionality.

~~~
didibus
Actually, lein and boot both use maven pom.xml and pom.properties as their
declared dependencies format. When you publish or pull a dependency, it
resolves it using pom.xml from the Maven repo, and when you push, they
generate the pom.xml for publishing to the Maven repo.

So this means that Gradle, Boot, Lein, Maven, and tools.deps all can consume
packages from each other seamlessly, and they all publish to the same
repositories in exactly the same format.

The only thing that is different are the way you create build steps and build
pipelines. As well as the way you declare your dependencies.

That's why there isn't any friction due to having multiple build tools and
dependency managers. Because the package manager is always the same: Maven.

~~~
uncletaco
Can you go backwards and generate a project/boot.clj from a pom file?

And can lein read from your boot file?

Because npm and yarn tag the same input, produce nearly the same output, and
can run tasks defined in the same location (the project.json). Does clj
tooling do that as well?

~~~
cbcoutinho
I'm not sure if you can create a project.clj, boot.clj, or deps.edn file from
a pom file, but there are at least plugins available that let one tool to read
the input of another. This plugin allows Leiningen to read deps.edn files for
example.

[https://github.com/RickMoynihan/lein-tools-
deps](https://github.com/RickMoynihan/lein-tools-deps)

~~~
uncletaco
I think this sort of shows what I'm getting at. Without plug-ins or extra
scripts yarn and npm take the same inputs, and yield the same output. A yarn
user can share a prokect with an npm user and neither will know nor care what
tool the other is using our how too make the tools talk.

This isn't to knock clojure tooling, which is good, but I don't think lein and
boot are drop in replacements for each other like npm and yarn (almost) are.

------
neilv
Suggestions:

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

~~~
cutler
A good way to get Clojure into your contracting work is with polyglot
solutions where Clojure, along with, say, Python sits behind a Node.js
gateway. Combined in this way Clojure is always accompanied by 2 of the most
popular languages - Javascript and Python.

~~~
ozim
So Clojure is useless and just stick to Python and Javascript. If you will
push some customer on such mine, hope you have liability limitation in
contract.

We work with big customer who is 90% Java, and we as C# shop have one project
with them. It is all time fights to get rid of us. But we are doing good work
and deliver so it is hard for them to kick us out.

~~~
cutler
Clojure has much to offer which isn't available in JS or Python. Immutability
and real concurrency for a start. I'm not sure what you mean by "pushing some
customer". That's not how I do business.

------
mdhughes
[Chicken Scheme]([https://call-cc.org](https://call-cc.org)) is fast, makes
native binaries, and has a giant library of "eggs" covering most of the SRFIs.
It's R5RS working its way towards R7RS. I've been using it for my "Python but
fast" code for the last year or so, and it's one of the best production
languages I've ever had.

[Chez Scheme]([https://scheme.com](https://scheme.com)) is super fast, and has
the best REPL I've ever seen, but can't easily make binaries, and has limited
external libraries. It's R6RS, which I prefer, but in the event you find other
Schemers to work with about half of them are going to be annoyed it's not
R7RS.

I found Racket to be substantially slower to compile and at runtime, the
library is weird and not what I expect of a Scheme, and DrRacket IDE has some
annoying quirks (it destroys your REPL environment every time you edit & run
source, which is just monstrous). It's really heavily designed around
educational uses, not so much production, and with the "Racket 2" changes it's
likely to fragment and chase off any serious users.

Learning one Scheme (with SICP, TSPL, etc.) gets you 95% of the way with any
Scheme; not so much with the three major LISPs (CLISP, Clojure, Arc). You'll
still spend half your time reading library docs and SRFIs, which is where they
all differ.

With any Scheme or LISP, you're going to face opposition from soi-disant
"programmers" who don't like to learn anything about programming, and managers
who don't want to support anything that isn't in the last 5 buzzwords they've
heard, but if you own your own project, it's pretty great.

~~~
Southy
Great response, I really like chicken when working on Mac or Linux, but it's
windows (where I do most of my development) that it struggles.

Some eggs just don't install and the error messages are really bad at that
point. Trying to install awful to develop a web api I had to give up, couldn't
find a way of getting it installed on windows (no problem on OSX or Ubuntu
18.04)

Installed Portacle and (ql:quickload "hunchentoot") and was up and running in
a few minutes.

A lot of lisp-languages could do with an equivalent to Portacle, an
opinionated dev environment that you can install and just start coding, an
area that Racket is excellent in.

~~~
mdhughes
I've never had a Windows, I'm a Mac nerd, but I'm looking into it for cross-
platform binaries.

Option 1: MS has a Linux subsystem now. Problem solved, but maybe not
customer-friendly.

Option 2: Cygwin probably works, I've seen John Cowan mention it in IRC.

Option 3: This somewhat messy process: [https://wiki.call-cc.org/compiling-
chicken-on-windows-xp-wit...](https://wiki.call-cc.org/compiling-chicken-on-
windows-xp-with-mingw)

~~~
Southy
Cygwin is the best option because you can easily access all of the installed
binaries for use with GUI emacs running in windows.

But I don't consider that to be a real native option, it is some kind of weird
halfway house that sort of installs linux binaries but they are also kind of
windows ones polluting your windows path.

Currently SBCL 'just works' on native windows, which puts it ahead for me if
you are happy with both Scheme and CL.

------
spiralganglion
I love Clojure, but I loathe Java, and I feel you do get exposed to a fair
amount of Java stuff when trying to work in Clojure. It's far better than it
used to be, but it's still too much for my liking.

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.

~~~
iLemming
> you do get exposed to a fair amount of Java stuff

Can you please expand on this? I've been using Clojure as my main PL for the
past 3 years, and honestly only once I had to actually deal with some Java
code (when I needed to figure out some Selenium stuff).

~~~
spiralganglion
When I learned Clojure, I also needed to learn about Maven, and POMs, and
JARs, and the Java classpath, etc — and encountering all that stuff for the
first time at the same time I was learning Clojure meant that I sometimes
couldn't tell what concepts were part of Clojure, and what concepts were part
of the Java ecosystem. This wasn't helped by the fact that the bulk of the
"how to compile Clojure" documentation was written assuming a Java background
(thus, assuming people would recognize the familiar Java stuff) — and when it
wasn't, it didn't bother trying to explain what parts were handled by Java and
why, because it assumed you didn't know Java so why bother explaining _all
that Java stuff that 'll be foreign to you, let's just gloss over it._ So the
result was that I was unable to learn how to deal with the Java ecosystem
parts of being a Clojure developer, so I had to go learn about the Java
ecosystem separately.

Contrast with ClojureScript — It has the same problems as above, but
substitute JS for Java and NPM for Maven, etc. I was coming from a web
background, so I could easily tell the JS-world from the CLJS-world. That
familiarity helped me tremendously in getting up and running.

The situation for CLJS is even better now with things like Planck and shadow-
cljs (and Shaun Lebron's cljs/tool and Cuttle before them), since those tools
mean you don't even need to install the JDK to get up and running with CLJS
(as it should be, I'd argue). The situation for CLJ is a bit better thanks to
the CLI tool. But the problems above could have been well handled by the
classic non-technical solution: really, really good official docs. That's been
getting better (thanks to Alex), but I'm pretty sure it's still going to be
more painful to get up and running with CLJ or CLJS than Ruby, Node, etc.,
sadly.

~~~
Jach
Reminds me of a metric the Clojure community has used in judging itself, which
is "time to first XML". There's now a helpful getting started page prominently
linked from the home page, which has no XML on it, but it used to be
[https://clojure.org/community/downloads](https://clojure.org/community/downloads)
was the main page and you'll note the XML is still there. You'd see that
before you even set things up, you're clearly in Java town now, buddy...

I like to use "time to first problem and the experience of its resolution" as
my own ruler. Maybe it's an XML problem ("wtf is Maven?") but it's usually not
until I try writing a program that I experience the first problem either at
compile time or runtime. I haven't been keeping up with Clojure (whose latest
version I've heard improved things on the error front) but when I first
learned, it wasn't long before I made a mistake and paid for it with a giant
Java stacktrace. I knew Java, though, so it wasn't a big deal to deal with it,
but some instances were quite frustrating since there was a disconnect between
useful messages about source locations when running code via a REPL connection
versus launching the program from scratch which involves loading and running
named Clojure files. It was rather subpar compared to Python, and especially
to Common Lisp, which has useful compile-time warnings on top of a superior
runtime error system.

Still I've always thought it'd be foolish to dive into Clojure without some
Java background, or at least without the anticipation of needing to get some
Java background, so it's interesting to read the contrary on this page...

------
finalfantasia
Based on your description, the Lisp that you're looking for should:

    
    
      - 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
    

Clojure checks every single bullet point on that list; it

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

Of course, you don't have to take my word for it, see what others have to say
about Clojure.[1]

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

~~~
Y_Y
Indenting like you have for your bulleted lists causes the text to be rendered
as code (monospace, no line breaks) which makes it very inconvenient to read
on mobile. Please consider this.

------
register
I suggest Common Lisp. If you can afford to spend money go with Allegro Common
Lisp or Lispwork. The best open source implementation is SBCL that works best
on Linux. If you want to avoid commercial implementations don't expect any
fancy IDE. You'll have to find what best suits you between Emacs and other
alternative plugins for the most common open source text editors. If you are
already familiar with Emacs then SBCL+Emacs+SLIME is a no brainer.

~~~
emit_time
The Allegro IDE puts syntax highlighting in the undo stack.

Better to use SLIME or the eli with it ;).

That being said, there are things you can do in the IDE that I don't believe
you can do in SLIME or eli.

------
newusertoday
If you don't want clojure, common lisp is the closest contender it has
excellent tooling, performant compilers (sbcl) and mature package management
however be prepared for rude shock when it comes to ecosystem support. Other
languages make up for the lack of lisp's power by having excellent support of
production grade libraries. You might struggle in doing soemthing basic like
talking to the chrome browser via cdp, you will have to roll your sleeves and
write your own, this looks fine initially but becomes tedious when you end up
creating too many libraries of your own for which solutions are readily
available in other languages. This is the reason why clojure is much better
choice as you still get access to all the java libraries. I wish there was
similar solution for golang so that you enjoy the power of lisp without
sacrificing the ecosystem support.

~~~
dimitar
For Clojure-on-golang there is [https://joker-lang.org/](https://joker-
lang.org/)

~~~
HerrMonnezza
Also: [https://www.ale-lang.org/](https://www.ale-lang.org/)

~~~
newusertoday
i didn't find anything on how to import go libraries into it.

~~~
andrenth
[https://gitlab.com/kode4food/ale/issues/5](https://gitlab.com/kode4food/ale/issues/5)

------
60654
If you want to use Common Lisp, the best implementation _by far_ is Allegro
Common Lisp from Franz ([https://franz.com/](https://franz.com/)). This is the
Lisp that gets used by research labs whose bread and butter is Lisp and AI
work, and their tooling (runtime, libraries, debugger, IDE, etc) is the best
bar none. I've used it for a while some years ago, and came away very
impressed. However, it _is_ a commercial product, and not free (but not as
expensive as some other commercial development tools).

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

~~~
soapdog
I always wondered about what people felt regarding Allegro Common Lisp vs
LispWorks. Have you used both? Can you share your impressions?

~~~
TurboHaskal
LispWorks is great for app development because of CAPI and its new iOS and
Android runtimes (although you cannot use GUI framework on mobile devices).
The IDE is also best in class. Add to that tree shaker and no royalty fee for
runtimes. Performance is better than SBCL for “real” applications.

Allegro is the only Lisp that can somewhat compete with Java on the GC story.
It’s simply the best Lisp you can use in the server. Even better than Clojure
in that regard as idiomatic Clojure tends to run quite poorly and doesn’t
allow for much low level tuning.

LispWorks for shipping binaries to clients. Allegro on the datacenter.

------
iLemming
> building production grade software

IMO Clojure is the only viable choice today (that fits your requirements)

\- Common Lisp (sadly) on the trajectory of becoming "Latin of Lisps". If you
seriously into Lisps, at some point you'd probably would have to learn it, but
practicality of that knowledge is slowly diminishing.

\- Racket is still quite "academic", not much of it is used in the enterprise
(in comparison).

\- Erlang VM lisps are even less popular.

\- There are a bunch of "smaller" lisps, like Fennel, but they are mostly used
by solo enthusiasts, and not for driving businesses.

Clojure is really nice. Clojurescript is probably the best AltJS alternative
today (compared to Elm, Purescript, ReasonML, Scalajs, Kotlinjs, GHCJS, etc.).
Clojure is extremely stable. And don't worry about Java. There's no need to
"dig into the Java world". There are tons of Clojure wrappers.

I think among FP languages Clojure is still the best choice today, because it
is "worst is better of Haskell" __* . Haskell is awesome, but: a) it is
indisputably hard b) it 's not a Lisp.

    
    
      * https://en.wikipedia.org/wiki/Worse_is_better

~~~
dorian-graph
> Clojurescript is probably the best AltJS alternative today (compared to Elm,
> Purescript, ReasonML, Scalajs, Kotlinjs, GHCJS, etc.).

Do you mind expanding on this? I’m moving away from Elm and I’ve been
considering Clojurescript, ReasonML, and Purescript.

~~~
iLemming
AFAIK FFI and use of existing JS libs is a pain in both Elm and ReasonML (that
is my subjective, empirical observation). Purescript is nice, but what would
you use in the back-end? Haskell? Or would you target nodejs? Deploying and
maintaining nodejs clusters is not fun. Using Haskell in the enterprise could
be fun, but getting to the level where it is fun is extremely hard. Finding
and hiring people is also difficult. Searching for a Haskell job is difficult.

People often dismiss Clojure for being dynamically typed, but it has Spec and
Spec is awesome.

People dismiss Clojure because it's JVM based, but they missed the fact that
JVM actually is pretty robust and very nice piece of tech.

People dismiss Clojure because "all the changes to the core have to be
approved by Rich Hickey", but they miss the fact how stable Clojure is. It is
hard to find a language ecosystem where you can pick any library written years
ago, bump versions of major components and expect everything to work.

I am not even talking about how people ignore Clojure because it is a Lisp.
That's just outright dumb.

There are no silver bullets. Any language ecosystem has its own limitations
and incur certain degree of frustration. Clojure nicely minimizes frustration.
It doesn't get rid of it completely (otherwise they wouldn't call it "work",
they'd call it differently and I wouldn't get paid for it)

~~~
dorian-graph
Thanks for the reply!

It being a Lisp is a positive point for me.

I'm not a fan of dynamically typed languages, but I'll have a look through
spec. From a cursory look, Clojurescript can use Spec as well.

------
raspasov
Don't worry, you won't need to dig into Java world. And to be honest, the Java
world is pretty good when you compare it to some other more fashionable
alternatives. After you spend some time with Clojure, it will become very
obvious which Java libraries are good and which frameworks are bad (pun
intended ;)). And again, the likelihood you'll need to do this is very low.
Many good and useful Java libraries already have Clojure wrappers or pure
Clojure alternatives.

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.

------
slyrus
SBCL is a great Common Lisp implementation -- and continues to be improved,
with version 1.5.5 just released this weekend.

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.

------
Grue3
SBCL. Works everywhere, super fast, has an advanced compiler with helpful
warning messages. You get a fully featured Common Lisp implementation with all
the goodies like CLOS, threads, C interoperability, and so on. And of course
no Java required (though there is a Common Lisp implementation (ABCL) written
in Java).

------
snazz
Most “progress” since CL has been very “one step forwards, two steps back”.
The interactive development, amazing debugging (don’t unwind the stack),
powerful macros, nearly-C-speed (if optimized), great tooling, etc. are
_mostly_ kept by other Lisps, but at the same time most every new language in
the Lisp family loses some aspect of what makes CL great.

[http://stevelosh.com/blog/2018/08/a-road-to-common-
lisp/](http://stevelosh.com/blog/2018/08/a-road-to-common-lisp/) is highly
recommended, as well.

------
andyjpb
I built

Knodium ( Demo video: [https://www.youtube.com/watch?v=gOPuWi-
dbQg](https://www.youtube.com/watch?v=gOPuWi-dbQg) ; Technical video:
[https://media.ccc.de/v/c116_lisp_-_2013-08-25_11:15_-_buildi...](https://media.ccc.de/v/c116_lisp_-_2013-08-25_11:15_-_building_knodium_com_with_scheme_-
_andy_bennett_-_1281#video) (sound comes in after the first couple of
minutes))

and

Registers.app ( [https://registers.app](https://registers.app) )

in Chicken ( [http://call-cc.org/](http://call-cc.org/) )

...and would recommend it.

The community in #chicken on freenode is really quite something. They're happy
to help with all sorts of problems, even basic ones and get stuck in over and
above expectations when problems get tough and technical.

------
i_feel_great
[https://wingolog.org/archives/2013/01/07/an-opinionated-
guid...](https://wingolog.org/archives/2013/01/07/an-opinionated-guide-to-
scheme-implementations)

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

------
kls
I think you should separate the concepts of Java (the language) and the JVM in
your mind while making your decision. You can absolutely write Clojure without
touching Java, but at some point if your app scales you are going to have to
understand optimizing and tuning the JVM, that being said, it's no different
than optimizing and tuning the underlying OS (from a conceptual standpoint),
it just happens to be a virtual run-time. You are not writing Java to tune the
JVM as most of it is set by parameters and config files.

If you are dead set on no JVM there is always ClojureScript.

For reference I have worked in Clojure, CL and a little Scheme, but would not
claim to be an expert in the latter two. From my experience Clojure is a LISP
built for building user centric apps, where many of the others are an
assortment of projects of people scratching their itch. Some good, some bad,
some complete and documented, some not. They are very powerful, but seem to
have less stewardship to keep the project on focus to be a dev platform for
building holistic applications for businesses.

while it gets linked to a lot in discussions like this, it's worth noting the
following article:

[http://www.marktarver.com/bipolar.html](http://www.marktarver.com/bipolar.html)

That is very much what CL and Scheme felt like to me.

Also to note, I have never worked with any of the commercial offerings for CL,
so take my opinion on the matter with the grain of salt that my exposure to
them has been limited to open source offerings.

------
slifin
Clojure doesn't mean digging into the Java world

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

~~~
twblalock
Clojure means running the JVM, and if you are serious about performance and
monitoring in production then it definitely means getting into the JVM world.
And let's be honest, most of the performance and monitoring tools are written
in Java.

Writing the code is really the first stage of commitment to a language or
platform. You are going to spend way more time running code than you spend
writing it. The choice of platform is therefore more important than the choice
of language in a lot of ways, and Clojure runs on the JVM (or some JVM-like
solution like Graal) so you better have some JVM experts around.

~~~
iLemming
I'm pretty sure, if someone goes on stage at any Clojure conference and asks:
"how many of you had to use JVM performance and monitoring tools" there won't
be too many hands. And if you ask "how many of you have to read or write Java
code every day to maintain your Clojure stack" there won't be too many hands
either. You don't need to be an expert in JVM to successfully build, deploy
and maintain stuff written in Clojure. It helps, but that's hardly a
requirement. None of the most popular Clojure books really dive into JVM - it
is not needed.

------
heinzemann
I looked at Clojure back in 2010, and from from 2012 I've managed to work with
it full time. Love it!

The only Java-esque thing you need to decipher are the potential stack traces.
But that's becoming easier with each new release, and it's actually quite easy
to find the Clojure-namespace (= file) and line number you need to focus on,
just by scrolling through the usually not too long stack trace.

~~~
sgt
Perhaps a silly question, but what would be the real-life benefits trying to
convert a Java team to Clojure in 2019?

~~~
iLemming
\- Productivity. Bulding stuff in Clojure is not only joyful but also can give
you real (not imaginary, not theoretical, but real, measurable) boost;

\- Concise syntax. Less code - less bugs;

\- FP. Immutability by default is something that once you get used to it, it
is hard to imagine having to write code without it;

\- REPL. I mean real REPL, not some kind of crippled "interactive shell".
e.g.: Jupyter is interactive shell, Clojure (just like any other Lisp) has a
"real" REPL;

~~~
sgt
Would you use the REPL to inspect / modify / debug running applications in
production, or would it mainly be useful for development purposes?

~~~
iLemming
If you do it right, you won't need to inspect/debug prod. But nothing stops
you from enabling socket REPL, connect to it and try things there. Just like
NASA fixed their failing spacecraft in 1998 during Deep Space 1 mission.

------
bitwize
Look into SBCL (Common Lisp), Racket (Scheme), or Guile (Scheme). All three of
these have enough library support to be used for real-world software
development and are designed to exist within a modern (usually Unix-based)
ecosystem.

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.

~~~
gjvc
>But don't try to introduce Lisp into your company, unless you are a cofounder
of that company. It's a career limiting move.

I think this is correct, unfortunately, due to the place in history lisp
occupied in the AI winter. As a result, it's looked upon as a failure, and
people tend to dissociate themselves from such things, even when there is a
body of evidence to the contrary demonstrating its efficacy.

Is that what you were alluding to or am I being too simplistic? I'm just
trying to expand on your remark. :-)

~~~
kazinator
Managers in a current company don't what "AI winter" is.

The whole "AI winter" meme is just a psychological complex in the mind of a
few old-time Lisp coders. It has no relevance today.

------
reagan
Given your background, consider trying out hylang, which transpiles to Python
and can use Python libraries. I played around with it a few times a couple
years ago, but never developed a serious project due to limited tooling. The
situation might have since improved. I've considered putting together an LSP
server for it because it'd fun to use for personal projects and scripting.

~~~
cutler
Yes, another vote for Hy. Just wish they had some more manpower to take it to
1.0. Be aware of "let" in Hy, though, as it's been removed from the core and
now lives in contrib. "let" is a major part of any Lisp IMHO.

~~~
rcarmo
Yeah, that was one of the main reasons I stopped using it. They’re doing async
now (which was another), but having let as a contrib macro and not in core
still puts me off a bit.

I wrote my entire blog engine on it -
[https://github.com/rcarmo/sushy/tree/master/sushy](https://github.com/rcarmo/sushy/tree/master/sushy)
\- and then ported it back to Python 3

------
jgrodziski
I've used Clojure several times for production-ready software and it's a
breeze to operate. Concerning production-readiness, here are my takes about
it: \- a major requirement is a good integration with infrastructure softwares
like databases, search engine, messaging, IAM. As Clojure is hosted on the
JVM, the integration is very simple with already available drivers for
Postgres, Kafka, Solr/Elastic Search (easier as the protocol is a REST API),
Keycloak, etc. \- Cloud integration, even for Serverless, is very easy: just
transpile to Javascript (Google Cloud Function) or Java (AWS Lambda) \- build
and package management are very mature with Leiningen, the latest "tools.deps"
have, IMHO, very interesting characteristics of simplicity (composibility at
core and simple "main" interface for invoking build process) \- You'll need
top notch security: OpenId with Keycloak makes it very easy to have a very
good IAM system (disclaimer: I make a Keycloak Clojure wrapper
[https://github.com/jgrodziski/keycloak-
clojure](https://github.com/jgrodziski/keycloak-clojure)) \- Good operability
is also a must-have: structured logging (look at Cambium), metrics
(Prometheus), good performance of the JVM, good monitoring and profiling \- On
the development Side, the productivity of using clojurescript with reagent/re-
frame and the development flow both on frontend and backend is a killer
argument. The possibility of isomorphism (running the same code on the
frontend and backend) makes it very easy to share the same domain between the
backend and frontend.

In the end, Clojure is amazing and fun, and it's production-ready for a long-
time. I made a talk at the Clojure Paris meetup 3 weeks ago (slides here:
[https://speakerdeck.com/jgrodziski/clojure-project-in-the-
fi...](https://speakerdeck.com/jgrodziski/clojure-project-in-the-field) only
the 3 first slides are in french, the rest in english).

------
mattxxx
> I've looked into Clojure and like a lot about it, but don't want to have to
> dig into the Java world.

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

------
pjmlp
Best Lisp would be the surviving ones from the commercial days, Allegro Common
Lisp and Lisp Works.

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

------
madhadron
Racket is my go-to when I need a small, cross platform GUI to put into
production. It's the easiest way to build a static executable for Linux, Mac,
and Windows from one codebase that I am aware of. So if that's your use case,
this maybe useful...

------
dutchblacksmith
I'm using Lispworks. Good IDE, solid and CAPI is a great for development of
IDE and graphics. Start using the free personal version and if you like it,
get in touch with them, they will help you. I also like SBCL+Emacs+slime+org-
mode.

------
tigroferoce
I suggest Clojure too. I have a few years of webservices production experience
with Clojure and must say that everything was more than fine.

You don't need to work too much with Java (even if you will have to work a
little bit with JVM if you plan to support things in production). The
toolchain is very good and the community is small, but nice. There are many
outstanding production-ready projects; my first hand experience was with:
MongoDB, MySQL, RabbitMQ and, of course, web servers, so if your stack
includes those, it is definetly a go.

I have also tried to deploy Clojure on AWS Lambda and it is definitely
possible, even if not sure if it production-grade yet.

------
thibran
Gerbil [https://cons.io](https://cons.io)

\+ modern

\- ecosystem

------
rcarmo
I tried out a bunch of Scheme implementations recently in search of one that
could build standalone binaries and had a moderately sane take on HTTP
requests for a pet project of mine:

[https://taoofmac.com/space/blog/2019/06/20/2310](https://taoofmac.com/space/blog/2019/06/20/2310)

That said, I would probably go with Clojure for other solutions, since the JVM
gives it a lot of reach and flexibility for real-world applications.

~~~
bjoli
Chicken is by no means an insanely fast scheme (even though it is fast
compared to many other dynamic languages). If you can get gerbil to work you
will probably have at least another 1.5-2 to gain.

~~~
rcarmo
I got it to work - in fact, here is my image:

[https://github.com/insightfulsystems/ubuntu-
gerbil](https://github.com/insightfulsystems/ubuntu-gerbil)

Chicken is plenty fast enough, though.

~~~
bjoli
Chicken is in many ways my favourite scheme. It is pragmatic and has what I
think is the most welcoming community I have ever encountered. Coming from
ruby and python to scheme, I was always surprised how fast things were. In
python I was always trying to avoid going outside the C things in the stdlib,
but in scheme I have gotten a fast experience while also being able to hack on
the code base (I am at best a bad C programmer).

------
fmakunbound
Well, what are you trying to build? Web applications? Number crunching?
Desktop applications? etc.

------
WorldMaker
Not entirely a joke, but: Emacs Lisp (elisp) is "evergreen" and likely always
relevant.

More seriously, the huge ML functional language family may still be worth
exploring, even if you really like/prefer the homoiconicity of Lisp/Scheme.
For instance, F# can be very production friendly at a lot of companies (it's
.NET-based and [mostly] well supported by Microsoft themselves and the .NET
Foundation), especially those with an investment in C#. .NET Core even has
some nice cross-platform stories today. You miss out on Lisp/Scheme's
homoiconic macros, but you still benefit from a lot of the functional-
programming first mindset.

Also, don't discount Common Lisp for not feeling "modern" enough. There are a
few CL distributions worth checking out, some with robust modern enough
package management. Definitely CL is a old ecosystem with a lot of old growth
forests, but that is a path to some structural stability too.

------
didibus
Clojure most likely. Why don't you want to dig into the JVM, it's arguably the
best production runtime out there.

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?

~~~
schpaencoder
Was thinking the same thing. Seems people conflate java with the jvm. The jvm
is almost as cool as the beam. Which got me thinking about the lfe, since we
are in lisp land.

~~~
cutler
A lot of developers have reservations about the JVM due to the way it consumes
available memory.

------
Tomte
Racket or Common Lisp, probably sbcl.

------
cutler
Clojure has 25000 libraries of its own so you shouldn't need to spend much
time in Java-land.

------
tlavoie
I tend to use Common Lisp for some personal projects, or small one-offs for
work to make something easier. Libraries are great, and easily managed via
Quicklisp (with info in quickdocs, as well as Hyperspec). And SLIME in Emacs
is amazing to use.

I've seen some comments that say, "well, if you use CL, that's all you know."
I'm not sure that it's a problem though, because the standard means that you
can often use much of the same code on multiple implementations, operating
systems and architectures. e.g., you're not stuck on the JVM, but can use it
(with ABCL). You can probably use the same implementation, like CCL or SBCL,
on Windows, Mac, Linux, on x86, ARM, and so on.

------
dizzystar
Clojure is the way to go. Years ago, the JVM leaked all through Clojure, but
now days, Java is mostly abstracted away from Clojure and you seldom have to
make those calls directly.

------
valw
From experience: you don't have to dig into the Java world for using Clojure
any more than you have to dig into the C world for using a Unix shell.

------
Jach
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-
de...](https://www.darkchestnut.com/book-common-lisp-application-deployment/)
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.

------
tankfeeder
[PicoLisp]([https://raw.githubusercontent.com/picolisp/picolisp/dev/READ...](https://raw.githubusercontent.com/picolisp/picolisp/dev/README)).
No open issues, everything is working.

------
zelly
Use Common Lisp (SBCL). When you have a problem in Clojure, you end up doing
it the Java way or importing some Java lib as a crutch. Lisp isn't meant to be
a batteries-included experience. You are supposed to be making your own DSL
for every program basically.

------
rauhl
I would suggest that you look into Common Lisp (no surprise to anyone who
knows me …). Why?

Well, it’s _solid_. I spent some years as a professional Python programmer,
and it was annoying how things which were easy to do in Lisp were difficult or
impossible to do in Python (e.g. change a file, reload it and have existing
objects updated with the new definitions). Common Lisp offers all the hooks
you might want to be able to mutate a system at runtime, but if you don’t want
to, then you can just ignore them. I find this very graceful: standardise the
possibility, but don’t mandate that one think about stuff one doesn’t need to
(yet).

Another aspect of its solidity is how well the standard (ca. 1994) has stood
the test of time. There are numerous implementations out there, and they all
support the same language (modulo some small bugs, no doubt). Common Lisp code
tends to be very portable, and tends to be easy to customise for different
implementations and platforms when necessary (the way that _FEATURES_
interacts with conditional reading of source is great). Libraries from twenty
years ago still just work. That’s almost unheard of in any other language I’ve
used.

Yet another aspect of its solidity is its error-handling capabilities,
unmatched in any other language I’ve used. Its condition system offers code
the ability to signal exceptional and non-exceptional conditions
(specifically, errors, warnings and signals), to catch such conditions, to
offer recovery strategies for such conditions and finally to choose between
recovery strategies for such conditions — to include prompting for human input
if desired. It is an amazingly powerful faculty. But like the ability to
handle runtime redefinitions, you don’t need to use it at all if you don’t
want to.

It’s high-performance, too, getting within an order of magnitude of the
performance of C.

This all means that Common Lisp can be used for quick hacks, simple scripts
and all the way up to long-running production systems.

To get started with Common Lisp you’ll want to take a look at Quicklisp, which
is the community-standard compilation of free software libraries. It hooks
into all the common implementations and offers a plethora of packages.

If you’re willing to use emacs (which I also suggest), then SLIME is very
good, but the commercial implementations also have their own excellent IDEs
which you might find you prefer.

I’ll be the first to admit that Common Lisp has some flaws, too — I would
_love_ to see a modern standard which specifies case-preservation as the
default, standardises threads (or something like Go’s channels and goroutines
…) and updates the pathname portion of the spec; I’d love to see something
which works out a few of the historical bits (like weird argument orders in a
few cases). But that stuff is _mostly_ just nitpicking, like complaining that
the breaks on a Lamborghini are the wrong colour.

------
stOneskull
[http://hylang.org](http://hylang.org) :P

------
lincpa
I wrote 100,000 lines of pure Clojure project, but never wrote Java. The
understanding of Java only reaches the of understanding the C-like OO language
syntax. This level is just enough to understand the Java API, so writing
Clojure does not require Java knowledge.

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](https://github.com/linpengcheng/PurefunctionPipelineDataflow))

------
twblalock
I assume you don't already have Lisp in production at your current company,
because if you did, you would already know which Lisp flavor to start with. In
that case, I would try to convince you that introducing Lisp to a company is
not a good engineering move, and not a good career move either.

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.

~~~
uncletaco
The OP was just asking where to start learning. Everything you've told them to
ask themselves are things that they won't have good answers to until _after_
they feel they can build a production ready application or honestly weigh the
costs of using the tools available with clojure vs. other language and their
associated tech.

How they can sell the app to management is way outside of the scope here I
think.

------
adamnemecek
I like Julia a lot.

------
PopeDotNinja
I am not that familiar with Lisp, but if you can't find something you like,
check out Elixir. I was showing him the AST for macro in had written, and he
said it looked very Lisp like. I've heard other people mention how it reminds
them of Lisp, too. I'll let others comment on how close it actually is.

