Clojure: The Documentary, official trailer [video](youtube.com) |
Clojure: The Documentary, official trailer [video](youtube.com) |
The fact that I can use the same language to develop business model code that runs on both the client and the server, or that I don't have to use a different on-the-wire format for sending data between them (EDN does the job great) is just icing on the cake in this context.
I am very thankful to Rich and the entire Clojure (and ClojureScript) teams for giving me access to all their work (for free!).
BTW, if you haven't seen any of Rich's talks, go see them — they are worth it even if you do not intend to use Clojure.
The very good backwards compatibility is attractive but as the result of the small community, there's also a lot of abandoned packages and fewer QoL packages (formatters, linters, etc); I know there are some but for example I had setup `cljfmt` in Emacs and it wouldn't work, didn't look further.
I'm not a hot shot programmer, entirely self-taught but a decent architect who thinks hard about problems, and with LLM agents Clojure shines for me. There are some fantastic databases also starting with Datomic -- free now thanks to Nubank -- and everything inspired by it and the Clojure flavor of Datalog. These include Datalevin, Datahike, DataScript, XTDB. Datomic itself is probably best for enterprise though there's now an embedded version.
But I'm pretty convinced that most LLMs I've used are more reliable with Clojure (and Elixir) than with most of the popular languages, and I can say they use Datalog extremely well, seemingly much better than SQL despite the vast difference in corpus size. For one thing Datalog just gets rid of joins issues.
I created my own job :-)
(although there are Clojure jobs in my area)
With LSP mode the standard `lsp-format-region` and `lsp-format-buffer` commands should work, and on the CIDER side `cider-format-defun`, `cider-format-region` and `cider-format-buffer` should also invoke cljfmt.
Clojure for me is a rich vocabulary to talk interact with data. When Jank becomes stable, Clojure will be unstoppable.
Both Clojure and Elixir really changed the way I think about programming. They’ve both basically ruined me as far as other languages go. Structural editing + repo driven development in Clojure, BEAM + pattern matching in elixir.
But there is something just infinitely more fun about writing Clojure code, and insanely satisfying. I’m eagerly awaiting the day that jank takes off and I can start building native mobile apps in Clojure (and who knows, maybe some web backend tech stack will spring up around it!)
In my experience, while I have found Clojure enjoyable and practical, it is still a "dynamic" language. A good deal of run-of-the-mill programming can manage quite well with such a language, but as projects become larger, deeper, and more complex, the lack of static types really does become a cost and an impediment. To understand any function and what it expects, you often need to read a few layers in to find what exactly something consumes and returns. Types really are a boon in such code bases. Some may point to various schema libraries in Clojure. While these can be helpful, they are often comparably inscrutable in practice (both in terms of specification and the resulting errors) and really do not compare to bona fide types, especially with LSP integration. And when you model something using types, the code sort of just falls out of the type definition.
I've worked with Clojure in a number of companies, it's an elegant language and a thing of real beauty when done well, but it's not so much fun when you're working on a codebase that doesn't respect the philosophy of avoiding breaking changes; especially when these breaking changes are done in library code, and where a more liberal approach has been taken when it comes testing.
"less ceremony, more responsibility" is a good summary, in a larger codebase a bit of ceremony is not always a bad thing though. I'm also glad I learnt Clojure, it made me a far better programmer.
Kudos to Mr Hickey, I'm looking forward to the documentary.
It seems like a small thing, but Clojure's choice to open up for other types of parentheses made seeing the structure of lisp programs much easier. This helped me understand how code is data and how macros are functions that can transform both code and data.
An important design philosophy (which is also hinted at in the trailer) is "simplicity". Clojure is designed to give you the tools to build simple solutions to the problems that you want to solve. It approaches mutability, which is one of the key sources of complexity in programming, with immutable data structures. It's a really clever way to do functional programming where your data is copied a lot but the copies are lightweight.
I don't write Clojure any more these days. I'm mostly doing Rust. But it is true what Eric Raymond said: Lisp has made me a better programmer.
Also: XKCD 224 and 297
Programming Clojure, Fourth Edition 4th Edition is on pre-order scheduled to be released May 2026.
https://pragprog.com/titles/shcloj4/programming-clojure-four...
The author recently weighed in on what he’d cut and add to a future version - could be useful to anyone reading today, if they want to skip some things. https://www.reddit.com/r/Clojure/comments/1rxknpj/quick_ques...
Clojure is a beautiful Lisp, and coupled with the JVM it's extremely powerful.
If you want a Lisp Machines like experience with Clojure, support the Cursive folks.
I hope more people get to experience this kind of joy :)
On the backend side, you start your server once, and whenever you change it locally, you apply what you changed directly to the running process, so you don't lose any state and without having to restart the server at all, so iterating on the program becomes very easy. Bugs are easy to track down too, as you can evaluate parts ("forms") of the program inside the process itself, debugging becomes a breeze.
On the frontend side, you have ClojureScript that basically enables the same but in a browser environment. Usually I have the browser on the right, my editor on the left, and whenever I "evaluate a function", it runs in the browser context, so again same thing; the frontend keeps the same state even after your changes, so no more "make change -> wait for compilation -> get frontend into the state that reproduces the issue -> output debug info -> make change again", you just change one part, see the page update and then continue changing.
If you've used React+Redux (or similar) before, it's basically that experience, but much tighter and together with code evaluation inside of the browser context. If I recall correctly, Redux was pretty much directly inspired by ClojureScript and Reagent in the first place, I think Abramov even referenced ClojureScritp/Reagent in the first Redux talk.
BUT
it doesn't have the equivalent of rails, mostly because lispers are an opinionated bunch and can't come together to agree on how web development should be done
the frameworks that do exist are more of a collections of libraries with some plumbing to connect the dots
See also Rich Hickey's remarks on AI: https://www.youtube.com/watch?v=MLDwbhuNvZo
— Rich Hickey, Effective Programs[0]
[0]: https://www.youtube.com/watch?v=2V1FtfBDsLU&t=4020s
---
A disastrously poor take. I used to work at a Clojure company, and there's no chance I'd ever go back to that.
I think the thing is that yes, `[a] -> [a]` tells you relatively little about the particular relationship between lists that the function achieves, but in other languages such a signature tells you _everything_ about:
- what you need to call invoke it
- what the implementation can assume about its argument
i.e. how to use or change the function is much clearer
if you are going to be modifying the same data with a sequence of functions, you got to write that down somewhere so new people get it.
Lisp is great at processing lists in such a manner.
Nothing wrong with that, having different target audiences makes sense and is probably preferable, but Janet is more than just "Clojure without the JVM" much like C# is more than just "Java without the JVM".
Obviously. The point being made is that the Clojure style discourages building DSLs and the like and prefers to remain close to Clojure types and constructs. It departs in various ways from traditionally Lisps.
does it really? https://github.com/simongray/clojure-dsl-resources
A good example is making GUIs in Clojure. At first there was a cool macro based system called `fn-fx` that maked a JavaFX GUI. Then vlaaad wrote `cljfx` which just used plain Clojure maps and removed the macros entirely. This increased the boilerplate a tiny amount but made the system much more flexible and extensible
"DSLs" can both mean "Using the language's variant of 'arrays' to build a DSL via specific shapes" like hiccup in Clojure does, and also "A mini-language inside of a program for a specific use case" like Cucumber is its own language for acceptance testing, but it's "built in in Ruby" in reality.
Clojure favors the "DSLs made out of shapes" rather than "DSLs that don't look/work like lisp inside of our programs".
Incidentally, I am having great success using AI with Clojure. In fact, from what I read online, better than most. I'm not sure if it's due to Clojure's terseness (and hence, token economy), or other reasons, but it works very, very well.
One big library/framework has huge benefits and network effects, from enabling a big 3rd party plugin ecosystem, to a deeper documentation literature (including paid courses, books, and AI). It means that there's less or virtually zero getting up to speed when changing from one project to an other. It means that the upstream framework team takes care of upgrades whereas you have to consider, when a new technology comes up, how to integrate this into your stack. There's a reason that Laravel, Django, Rails, and Spring each have thousands or hundreds-of-thousands of times more websites in production than all of Clojure combined.
At a meta/discourse level, I also find the Clojure community's tendency to constantly deny and downplay any criticism or even just issue that people face to be really frustrating and counter productive.
Yes, but this is intentional. Django developers are optimizing for "easy" which makes it fast to spin up project after project, Clojure developers are optimizing for "simple" which means way longer time to get the project of the ground, to nail all the design before things start to actually be put together, which makes it easier and faster to iterate on the same codebase after years of working on.
Ask the Django developer how easy it is for them to add features after a project they've done that approach with for N years, then compare it to a Clojure codebase, and you'll notice the difference.
Sure, I guess this is "downplaying" and "denying", personally I see people who disagree with me as people who disagree with me, that's fine, I thought that was why we were sharing our opinions in this forum in the first place. But anyways, if you're very deep into "frameworks are clearly superior in every case", that we disagree probably matters less. Best wishes regardless!
I think there are lots of well maintained Django projects. In fact, if I do a search on AI and on google for what one web stack probably has the lowest overall total cost of ownership including maintenance years down the line, Django usually is what comes up, without even specifically searching for/mentioning it.
> if you're very deep into "frameworks are clearly superior in every case"
This is a mischaracterization of what I have said, and is more like the extreme position that Clojure devs seem to take. The original commenter said that Clojure is wonderful, but it's too bad that [for the people who want it,] there isn't the option of a well maintained, all-in-one, batteries included framework. You deny that this is a problem, saying that actually a well-chosen set of libraries are superior (I guess in every case, because if not then it actually would be a problem sometimes).
This led to a lot of Clojure code being simple, but avoiding the hard additional work of also making it easy, and sometimes in even making it complete.
The prime example was tools.deps/deps.edn. It largely supplanted Leiningen for new code, but by being simple and minimal, it led to an explosion of ad hoc, custom tooling for 2-3 years afterwards, as everyone rewrote functionality that Lein already had, but tools.deps was missing. (And I say this as someone who once lost a whole week debugging a subtle maven/lein set ordering bug.)
a DSL is a constrained language for expressing domain concepts.
in traditional Lisps they are often syntax-oriented, because code is lists and macros are a natural tool.
in Clojure, pervasive use of keywords, vectors and maps allows you to shift DSL design towards data interpretation rather than syntax transformation.
so in Clojure doesn't discourage DSLs - clojure practicioners simply prefer data-oriented DSLs to macro-oriented ones, mostly because they are easier to reason about and process with existing tools, while macros are used more selectively.
> DSL is a constrained language for expressing domain concepts
What you're calling "data-oriented DSLs" is not constrained.
I guess this is all semantic, but in my book just specifying a data-structure doesn't make a language. You're not extending the host language in any way
constraints come from the interpreter, not from the syntax
> in my book just specifying a data-structure doesn't make a language
correct, it does not
what makes it a language is defining constraints on that structure and rules for how it's interpreted
that works both for clojure (where the data structure can involve lists, vectors, maps and primitives) and traditional lisps (where data structure is lists, or to be precise cons cells and primitives)
in both cases macros can be used and are used (but don't have to be used) to prevent immediate evaluation of those data structures according to host language rules and instead change how they are evaluated according to DSL author's rules
for example, datomic queries are just data structures, but they clearly form a constrained language with well defined semantics and the fact that they're not implemented via macros doesn't make them less of a DSL
But I'm not sure a framework is really going to change that onboarding process, or help with network effects that much. Elixir has a de facto framework, but it's barely more popular than Clojure. I mean, we had Leiningen starter kits and we have Kit. But what's confusing to me wasn't setting up a project, it was learning how it was wired together. Wiring small libraries together and just passing data can feel surprisingly leaky, and I don't really have to peak into the internals of Laravel the way I do Clojure projects.
I think Biff is a promising step in the right direction. I think the way it has wired things up is easier to follow. But for whatever reason, they made the choice to use XTDB as a default, which is a huge cognitive burden for newcomers. They have an article on how to use something else instead, but this is already getting out of the "it just works" territory if you haven't even learned Clojure yet. But the author is a really nice and talented person, and I am looking forward to seeing where it goes.
> I think there are lots of well maintained Django projects. In fact, if I do a search on AI and on google for what one web stack probably has the lowest overall total cost of ownership including maintenance years down the line, Django usually is what comes up, without even specifically searching for/mentioning it.
Having used Clojure, Laravel, Spring, and Django, I wouldn't touch Django again with a 10 foot pole. I don't know what you're referring to by "doing a search of lowest cost of ownership" but it sounds pretty unscientific. Anecdotally, I do legacy apps, and I have picked up people's Django apps, and I've never loved what I saw. It's a classic fast to start, slow to maintain framework. Huge businesses have been built on it, but huge businesses have been built on everything.
having one commonly accepted and recommended way does improve onboarding, because it collapses the decision space beginners face. right now they are supposed to make decisions (not even directly, but just through selecting one of the many frameworks) about things like:
1. which project templating tool to use? (lein, clj-new, neil)
2. which dependencies management tooling to use? (lein, deps)
3. which build tooling to use? (lein, tools build, boot)
4. which web server? (jetty, httpkit, undertow)
5. which routing library? (pedestal, reitit)
6. which templating engine? (hiccup, rum, selmer)
7. how to deal with javascript and it's build tooling? (clojurescript with a host of it's own decisions, bolt ts/js and wire it yourself, dodge that completely with htmx)
yes, multiple frameworks exist that make those choices for you, but then you inevitably hit the problem that some of the components haven't been updated in a while, so documentation is out of date and when you try updating it just for your project you need to fix the framework plumbing and due to number of frameworks, the corpus of useful information on the internet is quite fragmented and the community help is limited, and on and on.
none of this is good beginner experience.
and don't get me wrong, choice by itself isn't bad, focus on composability of smaller libraries is important, dominant framework is not going to improve anything when it locks people into bad decisions.
what we lack is convergence behind a single "reference stack" of libraries that ought to be good enough for the general case and a minimal framework of plumbing that doesn't require dozens of files just to get started.
there doesn't need to be a single way of doing it, but there needs to be a single recommended way of doing it.
What I'm suggesting is Elixir has everything you're talking about in Phoenix, yet it's still an extremely niche language most people haven't even heard of. Because come on, it's a totally different paradigm than what people are trained to program in. I understand the mental math of "easier means more people," but I don't think that's really going to cut it for Clojure. I had full projects spun up the minute I started learning, but that wasn't where the difficulty was.
So yes, I think having a solid framework is good for Clojure, but the original person suggested it's not popular because it doesn't have one, and I just don't think that's true.
This to me, seems to indicate they're talking about "DSLs not built with Clojure types and constructs", I'm just trying to have the most charitable reading of what people write and help you understand why it seems you're not actually disagreeing, just talking about different things.
and in context of lisps that still most likely means macro-based DSLs using traditional lisp constructs ¯\_(ツ)_/¯
i agree that it's not a sufficient condition, but it's an important factor and it would significantly improve the onboarding process by collapsing the decision space beginners have to navigate
even going by your definition of onboarding (the effort of getting more people) - dispersing that effort across multitude of dimensions and directions is certainly less effective than coordinating and converging
not intending to have an argument about popularity, but since you keep bringing up elixir - there's a lot that can be said about elixir/phoenix as to why they aren't more popular than they are, but they are more popular than clojure in every recent ranking i've checked ¯\_(ツ)_/¯
if anything, elixir/phoenix is a good example for how strong default improves onboarding and ecosystem cohesion, even if it doesn't make the language broadly popular
i don't look at it from perspective of "what should clojure do to be more popular than php" - there are fundamental reasons why that just can't happen in this timeline
i look at it from perspective of "what does this ecosystem lack that makes it hard for beginners to get going and stick"
and lack of "single recommended way of doing it" is at the top of my list