[HN Gopher] Official Clojure Documentary page with Video, Showno...
___________________________________________________________________
Official Clojure Documentary page with Video, Shownotes, and Links
Author : adityaathalye
Score : 319 points
Date : 2026-04-16 19:32 UTC (1 days ago)
(HTM) web link (clojure.org)
(TXT) w3m dump (clojure.org)
| mkw5053 wrote:
| In a previous life, I wrote Clojure every day and still look back
| fondly attending Clojure/Conj and sitting next to Rich Hickey and
| other Clojure greats at dinner.
|
| My first startup was all Clojure. AWS only had a dozen or two
| products and I think we must have been the first to compile
| Clojure to JS and run it on Lambda in production (the only
| runtime was Node.js 0.10 at the time).
|
| Anyway, I cannot wait to watch this
| xmonkee wrote:
| How do you feel about it now? Like holistically.
| mkw5053 wrote:
| I miss it. I'm now more removed and building software as a
| means to an end.
|
| I miss it just like I miss the program language and type
| theory group meetups in SF and working through problems in
| dependently types languages like Idris and being out of my
| depth.
| wazHFsRy wrote:
| I felt exactly the same, but recently started building side
| projects again in Haskell and fell in love again. Really
| brought my passion for software development back. 2026
| feels perfect for that, as AI can help with things where
| one was stuck, not the stuck in a good learning way,
| forever in the past. Now is the time!
| LandR wrote:
| I love the clojure, but I think a big downside is not being
| able to use it at work and now work feels like I'm being
| forced to work with stone age tools in comparison. That gets
| quite depressing sometimes.
|
| Sometimes I think I was happier before I learned Clojure.
|
| Ignorance was bliss.
| throwawaygod wrote:
| What are you using now? how do you feel about clojure now?
| mkw5053 wrote:
| I'm no longer in a professional engineering position and have
| a family and toddler so less time for learning about or
| playing with program languages. Clojure is what really made
| me first start thinking about programming languages and down
| the rabbit hole of scala and Haskell and idris and type
| theory books. Which are incredible and I can't recommend more
| and also not remotely practical.
| chii wrote:
| > also not remotely practical.
|
| studying them makes you smarter, which makes you better at
| using the practical stuff.
| TurboHaskal wrote:
| It also makes you bitter, at least in my experience.
| mkw5053 wrote:
| Completely agree, I guess I meant if you're writing an
| application you're going to be a lot less productive
| using Idris.
| LandR wrote:
| I love the clojure, but I think a big downside is not being
| able to use it at work and now work feels like I'm being
| forced to work with stone age tools in comparison.
|
| Sometimes I think I was happier before I learned Clojure.
| iLemming wrote:
| I never understood this sentiment. Even if nobody on my
| team uses Emacs or Vim, or Clojure, Rust, Zig or Nix, or
| some browser extensions, or any other tool, nobody could
| ever directly deny me access or restrict the use of any of
| that on my machine, some vm-box or EC2. And once I prove
| their usability to me personally, I show that to my
| colleagues and typically people when impressed they start
| using them. Once you have more than three people, you can
| start discussing rolling it out for general use. Just this
| past year alone, I have convinced my teammates to use a
| bunch of tools they'd never heard of before.
| agentifysh wrote:
| is clojure still relevant in the post agentic coding reality that
| opens up pretty much all esoteric languages to everyone ?
|
| back in the day used to use clojure to write a fintech app but
| not sure if it is still relevant has uses vs other langs that
| have emerged
| netbioserror wrote:
| Clojure might be the least esoteric language ever. Call a
| function, get a value.
| agentifysh wrote:
| It definitely is more "mainstream" than others but I just
| don't see the same level of attention and enthusiasm around
| it anymore. I'm sure it is still being used in many places
| but like Elixir, hiring remains on the tough end.
| iLemming wrote:
| Hiring good talent was always problematic. This has nothing
| to do with the quality, capacity, and robustness of the
| language or its relevance. Hiring people who would love to
| use Clojure but have no prior experience is not that
| difficult - it's just that every company wants an expert,
| but they don't want to offer expert salaries. In places
| where they do, the competition is nuts, on top of that,
| experienced Clojuristas typically get interviewed and
| scrutinized with the same level of rigor as architects.
|
| The industry should have optimized for hiring people
| interested in PLs like Clojure instead of LeetCode
| drillers. Clojure is rarely the first, second, or even
| third programming language people choose to learn. It
| demands a specific vision, dedication, and discipline that
| fundamentally transforms how people think about
| computation, data flow, distributed systems, and
| concurrency. The ROI from hiring an average developer
| experienced in Clojure has the potential to significantly
| exceed that of a typical hire. Even when there's zero
| Clojure in prod.
| acheron wrote:
| I've had Clojure on my resume for 10 years, mainly to see
| if anyone would ask about it. Nobody ever has, until an
| interview a couple days ago. We'll see if it actually
| helps in leading to an offer, I guess.
| iLemming wrote:
| I have the opposite experience - been using Clojure for
| over a decade and it feels like only that mattered for
| the last five jobs. Even though it's really only just one
| of many layers that required to do the job. I honestly
| would love to find a non-clj team and convince them to
| use it. There are so many useful scripts we write in
| babaska alone, it just sounds wasteful not to use that
| path, fully knowing of its existence.
| uxcolumbo wrote:
| Can you talk more about those scripts, what are you using
| it for?
| iLemming wrote:
| Anything that we previously used Bash or Python for - any
| complex task delegation from GHA; utility scripts for
| setting up proper ssh tunneling for various k8s clusters;
| there's pretty complex CLI tool we build for testing our
| services in ephemeral SDEs running our pods.
|
| Personally: all my MCPs are written in Clojure -
| https://github.com/agzam/death-contraptions; I write
| small web-scraping scripts and automations in nbb with
| Playwright. The flexibility of starting the REPL and
| figuring out the rest of it dynamically, while poking
| through DOM elements directly from the editor is some
| blackmagicfuckery that should be outlawed. Imagine being
| able to control the state of the web browser while typing
| some incantations in your editor, without much ceremony,
| without some crazy scaffolding, without "frameworks",
| without even having to save the code into a file. You
| gotta be some ignorant fool who doesn't know this was at
| all possible or a complete idiot to say "meh, but all
| these parentheses". You gotta be kidding me. It's like if
| someone gave you a magic car attachment that makes it run
| for 800 miles on a single charge and you'd say: "meh, I
| don't like the color of it"...
| embedding-shape wrote:
| Imagine what you'd use random shell scripts,
| Makefile/Justfile or whatever "scripts" the language
| offers, if any, but written in Clojure instead, run with
| Babashka.
| yogthos wrote:
| Clojure is more relevant than ever in post agentic coding
| because of immutability and the REPL. The two big problems with
| agentic coding is context growing in unbounded fashion, and
| agents being able to get quick feedback on what they're doing.
| Mainstream languages fail on both accounts. I've found Clojure
| has been a great fit for keeping agents on track.
|
| I've wrote about this in more detail here if you're interested
| https://yogthos.net/posts/2026-02-25-ai-at-scale.html
| MarkMarine wrote:
| One of the main problems I have with the models coding is the
| feedback loop is way down the chain from generation, it's out
| at the commit boundary for python when your hooks are running,
| maybe at the point where the model wants to push a PR. The REPL
| lets that happen during generation, and the other safety
| measures help immensely. Immutable data, STM, all of the
| features in Clojure that gave devs super powers now do the same
| for a model.
| hsaliak wrote:
| Clojure had lousy error messages, agents deal with this well.
| Clojure is capable of producing some of the most dense code
| I've ever seen, so manual code reviews really start to feel
| like a bottleneck unless your goal is to level up.
| tosh wrote:
| I would say dense code tends to help code reviews. It just is
| a bit unintuitive to spend minutes looking at a page of code
| when you are used to take a few seconds in more verbose
| languages.
|
| I find it also easier to just grab the code and interactively
| play with it compared to do that with 40 pages of code.
| embedding-shape wrote:
| > Clojure is capable of producing some of the most dense code
| I've ever seen, so manual code reviews really start to feel
| like
|
| For me it's the opposite, the dense code is easier to review,
| because the proposed changes are almost always smaller and
| more informative. Contrast a change in a typical TypeScript
| project where changes propagate across tens of files, that
| you need to jump in-between just to understand the context.
| In the time it takes me to ramp up understanding what the
| change is, I've already completed the review of a change in a
| Clojure program.
| asa400 wrote:
| Couldn't agree more. And I actually kind of like
| Typescript, but man, typical Typescript projects are so
| verbose and sprawling, it's crazy.
| iLemming wrote:
| Not to mention that Clojurescript often emit safer code
| than Typescript does. Sounds insane and counter-
| intuitive, but here's the thing - Typescript actually
| removes all the type information from the emitted JS.
| Clojure, being strongly typed retains the strong typing
| guarantees in the compiled JS code. So all that enormous
| amount of effort required to deal with complex types, in
| practice feels like bringing kata choreography to a
| street fight - it's not utterly useless by itself, but
| hardly helping in a real fight-or-flight situation. You
| can impress the attacker with your beautiful dance and
| even prevent them from attacking you, but that's more
| like hope than a real strategy.
| iLemming wrote:
| I find it actually the best substrate to write AI tooling. All
| my custom MCPs are written in Clojure (bb). You hook up the
| agent to the REPL and let it go wild - it builds something
| nice. Also, Clojure is one of the most token efficient PLs.
| arikrahman wrote:
| I would say with the nREPL feature and letting the AI Agent
| jack in, Clojure may actually be the most well positioned
| language for this use case.
| jwr wrote:
| I work on a large Clojure codebase with AI, and I'm getting
| _excellent_ results. Likely factors are code density, the
| resulting token density, and a lot of well-architected code
| that the AI can follow -- I 'm not sure exactly, but the
| results are _really_ good.
| slifin wrote:
| Yeah I see this at work - people are sceptical that AI +
| Clojure even works
|
| but in my experience its amazing the overall quality of
| Clojure code in the wild tends to be higher than your typical
| language so AI's training on Clojure tends to be on modern
| and high quality code and the language is very token
| efficient, you can also tell AI to interact with the REPL to
| avoid restarts
|
| The only downside I've seen reported is mis-matched parens
| but for me models have been strong enough to balance parens
| for about a year at least it's not something I actively work-
| around even though there are work-arounds like brepl and
| others
| jwr wrote:
| > mis-matched parens
|
| FWIW, I _never_ get mis-matched parens when working with
| Claude Code in Clojure. I guess the key is to use clojure-
| mcp tools. If there ever is a mismatch during work (rarely,
| but I 've seen it happen), claude fixes it using the tools
| right away.
| yogsototh wrote:
| Personally this is a hidden trick I use.
|
| Ask AI to build something. By default it will use python.
| Sometimes js or typescript.
|
| Ask then to do the same thing in Clojure. The result is
| generally an order of magnitude better. Shorter, easier to read
| for both humans and llm. Easier to adapt to changes.
| embedding-shape wrote:
| Not to mention that changes are easier to review, because
| there is less of them. Same semantic diff for JavaScript and
| Clojure looks vastly different, and I'll favor to review
| Clojure changes any day of the week.
| erichocean wrote:
| Autochrome [0] make reviewing Clojure diffs from AI really
| easy.
|
| [0] https://github.com/ladderlife/autochrome
| asa400 wrote:
| This is like asking if violins are still relevant because we
| have cars now.
| TacticalCoder wrote:
| Incredible: I had not idea NuBank discovered Datomic first and
| that it's Datomic that led them to Clojure, 100 million+
| customers, and eventually acquiring Cognitect.
|
| Good to see David Nolen (aka "swanodette") is in the documentary
| too.
|
| As a bonus here's a recent talk from David Nolen about
| Clojure/ClojureScript and using DOM morphing instead of React.
|
| If you don't want to watch it all, just take two minutes to watch
| from 23m15s to 25m15s. He compares a behemoth slurping all the
| browser's CPU and RAM resources versus a 13 Kb of JavaScript +
| Web components and DOM morphing:
|
| https://youtu.be/BeE00vGC36E
|
| His talk is presented from Emacs, gotta love that too...
| mkw5053 wrote:
| I don't know if it's still the case, but at old clojure
| conferences, or meetups, or places of employment, emacs was a
| prereq and assumed (and the most enjoyable)
| adityaathalye wrote:
| I think it was more like Emacs got Clojure development
| niceties early, particularly tight REPL integration.
|
| Things have been different for well over five years --- about
| a third of Clojure's life. There are so many first-class
| options now. When teaching Clojure, I direct everybody to
| either VSCode + Calva, or Intellij + Cursive.
|
| LSP has really upped the game too. I rebuilt my Emacs
| development workflow around LSP for all the things.
|
| These days, I sometimes forget to fire up the REPL, because
| of all this fantastic "static analysis style" developer
| tooling by borkdude and eric dallo.
|
| Much gratitude to all the toolsmiths from all over the
| Clojure ecosystem. Special shout-out to LightTable for upping
| the game for everybody. I was very sad when the project went
| dormant.
| lemming wrote:
| _Things have been different for well over five years..._
|
| In fact, I first presented Cursive at the conj 2014, and
| I'd been working on it in open beta for perhaps a year
| before that, so well over 10 years!
|
| _...all this fantastic "static analysis style" developer
| tooling by borkdude and eric dallo._
|
| _ahem_
| adityaathalye wrote:
| Cursive has been way ahead of the curve, yes. Sorry
| Colin, I'm both emacs-addled and fuzzy with timelines :D
|
| So think of it more like "static analysis stuff for the
| _rest of us_ " :D
| lemming wrote:
| Hehe, Lisp Emacs Myopia is indeed a real thing. Cursive
| users have been not starting REPLs for over a decade now!
|
| j/k of course, and no offence taken :-)
| iLemming wrote:
| Thank you Colin for the outstanding work and selfless,
| continuous gifting and self-generosity. Cursive remains
| one of the important pillars of Clojure journey for many
| beginners and seasoned pros.
|
| You just can't ignore the amazing collaboration and
| camaraderie between Clojure tools builders. - you Colin,
| Peter (Calva), Eric (clojure-lsp), Michiel (babashka,
| kondo, etc.), Bozhidar (CIDER, clojure-mode), Juan
| (flowstorm), Chris (Portal), and many others.
|
| Everyone, instead of competing with one another just
| wants for people to find their best way of using Clojure,
| and that is really awesome. You can see the ideas freely
| circulating between spaces and creating great of
| awesomeness for everyone in the community. I'm telling
| you all this as someone who doesn't even use Cursive. I
| still can see your work. I can tell how valuable,
| important and vital you are for me personally and for
| many of my friends and colleagues. I salute you, and
| every other tool-making hero. Thank you, guys!
| pjmlp wrote:
| Emacs has always had a tight link with Lisp communities, due to
| its history, including ties to Lisp Machines, so naturally many
| use it.
|
| However, as someone that rather use Lispworks, Allegro, Racket,
| there is also Cursive on top of InteliJ.
|
| However note that XEmacs was my IDE replacement during my first
| UNIX decade, due to lack of proper alternatives, so I do know
| about what Emacs and its derivatives are capable of, no need
| for yes but replies.
| pgt wrote:
| Datomic was the reason I switched [^1] to Clojure as my primary
| language in 2014. It was a gamble, but it paid off in the end.
|
| I maintain that Clojure is the best AI-first language due to
| the lightning-fast iteration via the nREPL and Clojure's token
| efficiency.
|
| [^1]: https://petrustheron.com/posts/why-clojure.html
| ajdegol wrote:
| didn't know datomic was free of licensing fees - I didn't use it
| back in the day because the cost was prohibitive... interesting
| dimitar wrote:
| It is!
|
| And also it has inspired a few other clojure datalog databases,
| so there is much more choice: *
| https://github.com/datalevin/datalevin *
| https://github.com/replikativ/datahike *
| https://github.com/threatgrid/asami
|
| There is also xtdb, but it abandoned datalog and is going in
| another (albeit interesting direction) https://xtdb.com/
|
| here is a comparison website, but it is somewhat out of date:
| https://clojurelog.github.io/
| malindasp wrote:
| The double belt buckle is a pretty classic diffusion model
| artifact -- it struggles with symmetrical accessories because
| it's essentially pattern-matching textures rather than
| understanding "this person is wearing one belt." Same reason you
| see six-fingered hands.
|
| The repeated code on the steps is actually the more interesting
| tell to me. An artist would vary that deliberately for visual
| interest. A model just tiles what it learned looks like "code."
|
| That said, the pencil sketch theory is compelling. Hybrid
| workflows where a human does the composition and an AI handles
| color/rendering are increasingly common, and they produce exactly
| this kind of uncanny result -- strong underlying structure with
| strange surface artifacts.
|
| Whether it is or isn't AI, the irony of a documentary about a
| language whose community deeply values craft and intentionality
| potentially using generated art for the thumbnail is at least
| worth a raised eyebrow. Not outrage-worthy, just... a little
| incongruous.
| JB024066 wrote:
| According to the documentary group it was hand drawn:
|
| https://www.linkedin.com/posts/cult-repo_call-us-old-fashion...
| puredanger wrote:
| It was hand drawn by an artist. Indiana Jones (the obvious
| inspiration) wore two belts, one for his pants, one for his
| whip/holster. The code was provided by Rich.
| christophilus wrote:
| Excellent. The only thing I wish they had added was borkdude.
| iLemming wrote:
| Yes, sad there's no European presence (unless I missed
| someone). There's tons of Clojure over there. Metosin, Juxt,
| Borkent, Gaiwan (Arne), Flexiana, Peter Stromberg (Calva),
| Dustin Getz (hyperfiddle/electric), Christophe Grand
| (ClojureDart), Bojidar (CIDER), Renzo, and many, many more.
| macmac wrote:
| I agree. Probably a cost issue as all interviews appear to be
| done in person.
| iLemming wrote:
| They could've cut Zoom interviews in there - they are not
| expensive. The documentary creates a skewed image of
| Clojure being mainly in Americas, while in fact the big
| chunk of it is on the other side, where they have more
| conferences, (probably) more startups and (perhaps) people
| using it.
| simongray wrote:
| I am pretty sure Dustin Getz is American.
| iLemming wrote:
| Oops, my bad. Someone on hyperfiddle/electric core team is
| in Europe, I think, but now I'm not sure about that either.
| pjmlp wrote:
| Clojure is my favourite alternative language on the JVM, besides
| offering what Lisps have provided for decades, their philosophy
| of embracing the host platform, instead of all the talk that the
| next JVM will be rewriten in it like some others do, makes being
| around Clojure folks much more appealing.
| dgb23 wrote:
| When I was younger this actually irked me a bit. I wasn't
| familiar with either, so it felt burdensome to me. The tooling
| also wasn't as good as it is now.
|
| However there's no doubt that this is one of the primary
| reasons why Clojure became relevant and widely used (for a
| niche language). Seamless integration (or even improved
| integration) is very useful.
|
| Another language that takes this approach is Zig. My intuition
| is that here as well, it's a unique selling point that will
| help with adoption and day to day usefulness.
| boriskourt wrote:
| I've been using Clojure since 2013, and can say that it has been
| an enormous positive force in my life. I've been a very
| unorthodox user, most of my artworks were built using Clojure in
| some way. But I've also worked in industry, and there I think
| Clojure helped me avoid burnout on more than one occasion.
| Especially when running a startup built half on it :)
|
| It's also been a privilege to participate in the community. From
| Clojure west to the Conj, to the online discussions. Huge thanks
| to everyone that's made this possible over the decades.
| ch4s3 wrote:
| I'm not sure what you use ti for, but your website is beautiful
| and your work is really striking.
| boriskourt wrote:
| Thank you! I've managed to shoehorn Clojure into everything
| from 3D model generation to VR networking servers for
| installations :D It makes so many things easier to reason
| about!
| ch4s3 wrote:
| Very cool. Anything open source/on github?
| boriskourt wrote:
| I wish I had a chance to open source. So much of it was
| done in mad hacking sessions to glue things that were
| never supposed to work together. Or contain all the
| secret sauce for one work or another. Maybe the next one!
| ch4s3 wrote:
| makes sense. I'll keep an eye on your site.
| slifin wrote:
| Looking back Clojure has been the best thing to happen to me in
| this industry
|
| I doubled my salary using it and changed industries to much more
| stable industries
|
| I've been to a lot of conferences and meet ups in my career but
| the feeling of joy and inclusivity at Heart of Clojure was unreal
|
| The community is still alive and well, my favourite passionate
| sub culture in the Clojure community at the moment is the Jank
| community, building a Clojure Dialect for low level work an
| incredible amount of work but they're doing it anyway
|
| The problem is businesses aren't really interested in stability
| integrity or joy when it comes to their languages they want to
| commodify their developers by forcing them to write the most
| popular and replaceable languages possible
|
| Then they're surprised when the quality of developers they're
| able to hire drops and the quality of their software drops it's
| all just a race to the bottom - emboldening companies to try and
| replace developers with AI and destroy their own companies in the
| process
|
| What surprised me the most in working with Clojure commercially
| is how many commercial developers did not get the ethos of the
| language or have watched the rich hickey talks or use the REPL,
| all they see is restrictions and unfamiliarity I don't know how
| these people got hired without a passion for the language - lots
| of them get promoted to run Clojure codebases
| embedding-shape wrote:
| > What surprised me the most in working with Clojure
| commercially is how many commercial developers did not get the
| ethos of the language or have watched the rich hickey talks or
| use the REPL
|
| Yeah, this continues to stick out. The amount of people I've
| come across who do Clojure development and restart the
| application (really, the JVM process, kill it and launch it
| again, over and over!) is way too high, considering the first
| "real" reason I had for moving wholesale to Clojure was a
| shorter feedback loop. If that's not one of your goals when
| moving to Clojure, I'm not sure what you're up to really.
| jgalt212 wrote:
| Yes, but without a clean REPL you can't easily be sure that
| your var definitions are what you think they are.
| embedding-shape wrote:
| Sure, so once a week or so you need to restart the process
| if you end up like that.
|
| What I've seen people do, is restart the process after each
| change like you typically do in other languages, rather
| than evaluating the current form...
| cfiggers wrote:
| The thing that happens to me is that I'll get something
| working in the REPL, then try to deploy it and it breaks
| --because unbeknownst to me, I had gotten my REPL into
| some state where everything was working, but a cold start
| doesn't look the same.
|
| Is this a skill issue? Absolutely. Do I still restart the
| REPL frequently (not after every def, but often) just to
| make sure I'm working with the same environment my
| program will be experiencing at run time? Yes I
| absolutely do.
| Folcon wrote:
| Couldn't you have one test that requires your -main and
| runs it?
|
| Just fire that off every now and then?
|
| Basically the same thing, but you don't lose repl state
| embedding-shape wrote:
| Ah yeah, been there, and probably the first time was when
| renaming a function but missing to update callers, so
| callers keep calling the old function, and you have no
| idea why the changes you made in the new function aren't
| working.
|
| I have a this little function for clearing the current
| namespace that I call every time I rename any var inside
| a namespace: (defn clear-ns []
| (map #(ns-unmap *ns* %) (keys (ns-interns *ns*))))
|
| Not a perfect solution, but personally I also don't know
| a better solution that doesn't involve loosing out on
| other (non-negotiable for me) benefits.
| mvc wrote:
| Once a week?! Aren't you killing the repl at least to run
| a full test suite without any stale leftover developer
| state before deploying?
| embedding-shape wrote:
| Full test suites I run before committing essentially, in
| a separate tab altogether, then the full suite is
| typically also run in CI before any deploys.
| TacticalCoder wrote:
| > Yes, but without a clean REPL you can't easily be sure
| that your var definitions are what you think they are.
|
| vars and functions too. It's the biggest issue: the
| inevitable mismatch after a while.
|
| As soon as I've got any doubt there might be a stable cache
| or a mismatch, I'll just "nuke the current CIDER buffers
| and relaunch _cider-jack-in-clj &cljs_". And it takes 1.3
| seconds.
|
| I'll also regularly spawn, from a terminal next to my
| Emacs, all the unit tests related to what I'm working on,
| in its own JVM / process(es). I'm not talking about running
| tests on commit (which I can do too). I'm not talking about
| running tests when I modify a function.
|
| I was there 3000 years ago when Java 1.1 was using green
| threads on Linux and using Java on Linux required a serious
| leap of faith (but I knew... I knew it'd take the world...
| And I knew great things like Clojure would then come).
|
| Now a JVM starts and exits in 40 ms.
|
| Emacs starts and exit, with 4 000 lines of elisp
| customization I created over the years, in 1.1s.
|
| I _cider-jack-in-clj &cljs_ spawning both a CLJ and a CLJS
| REPL in 1.3s.
|
| Clojure devs definitely _should_ modify vars and redefine
| functions at runtime and use the REPL etc.
|
| But there's no need to let a REPL live for one week like GP
| is suggesting. I can launch my entire app, including Emacs
| and two REPLs, in 2.5s. While at the same time having all
| my unit tests being launched in another process.
|
| At 2.5s to "restart the world", there's no reason not to do
| it more than once a week.
|
| P.S: also stale caches are a thing in this world. It's sad
| but it's simply how it is. How it's always been. Restarting
| the whole world, while in dev, helps also deal with a great
| many stale caches issues that may not be related to Clojure
| but to other things ( _e.g._ I didn 't invent the "disable
| cache" button in browsers' developer tools and there's a
| reason it's there).
| eduction wrote:
| I'm probably not the sort of person you're referring to, but
| I do regularly restart the REPL because
|
| 1. multimethods, if you change the dispatch fn you can't get
| it just with a recompile, there are tools to help with this
| but i'm not yet in the hang of using them after several
| years. (Many people don't hit this because they don't use
| multimethods. I love multimethods for the use cases I've hit
| so far with clojure.)
|
| 2. interceptors (pedestal) - I love this pattern and lib, and
| they've made moves toward improving repl friendliness, but I
| find I need to recompile two NSes typically to get a true
| reload even in dev mode (the one where my routes are defined
| and the one where a particular interceptor chain is defined).
| sometimes i lose track of what i've reloaded, and I dont know
| if a bug is "real" or just an artifact of forgetting to
| recompile - "f it, just restart the repl"
| jwr wrote:
| I am so thankful for Clojure. It enabled me to run a solo-founder
| business for the last 10 years in a sustainable and maintainable
| way. It allows me to manage a large complex codebase
| (client+server) because of low incidental complexity and the fact
| that the server and the client share most of the business logic
| code.
|
| Also, thanks to the focus on stability and practical usage, I
| don't get my rug pulled out from under me every couple of years,
| like with so many other languages and environments. This is
| incredibly important and not immediately visible when "choosing a
| language to use", because the new shiny and the warm fuzzy are
| irresistible pulls. Clojure is not the new shiny and it's not the
| warm fuzzy, but it is your stable long-term companion for
| building complex software that is maintainable.
| bachmeier wrote:
| I've always enjoyed using Clojure. Unfortunately, most of the
| things I do require interacting with the C world, so it has never
| been a real option as my primary language.
| erichocean wrote:
| I also interact a ton with C and C++, but it's easy today to
| have Claude write a Project Panama wrapper and then put a nice
| Clojure veneer on top of the Java.
| perrygeo wrote:
| You might be interested in https://jank-lang.org/ - still early
| days but full C/C++ interop is the plan.
| andersmurphy wrote:
| Coffi [1] built on java 22 (project panama) C FFI. Makes
| binding to C from Clojure a lot of fun.
|
| - [1] https://github.com/IGJoshua/coffi
| smartmic wrote:
| Have a look at Janet. It is not as powerful as Clojure but for
| smaller projects, prototyping, scripting etc., it is really
| enjoyable.
|
| https://janet-lang.org/
| Unsponsoredio wrote:
| the "stable long-term companion" framing from jwr's comment is
| the part that sticks with me. every company I've worked with that
| chased the new shiny ended up spending more time on migrations
| than on the actual product.
|
| stability is boring to talk about but it's the thing that
| actually lets small teams survive long enough to win.
| mark_l_watson wrote:
| Clojure is a great language and ecosystem. I donated a little
| money to Rich's efforts in the early days (I loved his older
| Common Lisp - Java bridge so his Clojure project was immediately
| interesting) and I have been paid for a few years of Clojure
| development.
|
| I like maintaining the history in one place, nicely done.
|
| I don't use Clojure much anymore, but two hours ago I updated two
| chapters in my old Clojure book because the examples had 'gone
| stale' and that was fun.
| uxcolumbo wrote:
| What made you stop using Clojure or not so much anymore? No
| jobs in Clojure?
|
| Also, in your view, is Clojure better suited for ML / AI apps?
| And if so, what is stopping it from being more widely adopted.
| I read the interop with Python ML libraries is good?
| iLemming wrote:
| > what is stopping it from being more widely adopted.
|
| The best tools usually need a level of skill or patience that
| most developers just don't have time for. And companies have
| to ship with the developers they actually have, not ideal
| ones.
|
| Lisp, formal methods, immutability, property-based testing -
| we agree on these. They just demand more than most people can
| give under a real deadline. A tool that shines in expert
| hands but falls flat for everyone else will lose to a tool
| that's just okay for everybody. Every time. That's basically
| what "worse is better" means.
|
| In our industry we tend to approach things with "scientific
| methods", without actually using scientific methodology.
| Nobody experiments developing a real business solution with
| multiple teams using completely different set of tools just
| to see which one proves to have better ROI. What we do
| instead is that we go to forums and emotionally "mansplain"
| our anecdotal, subjective feelings about a tool or technique.
| Anecdotes aren't completely worthless; they're low-quality
| evidence, which is different. A senior engineer saying "every
| time I've seen a team adopt microservices before they had the
| operational maturity, it ended badly" is transmitting
| pattern-recognition from, say, fifteen projects. That's not a
| randomized controlled trial, but it's also not nothing. But
| there's flood of "unfalsifiable anecdotes" - claims
| structured so that any counterexample gets explained away
| ("you weren't doing real TDD...").
|
| Rich Hickey's talks are not science - they're argument from
| principles, with illustrative examples. But they're honest
| about being that. He doesn't pretend to have benchmarks
| proving immutability is better; he reasons about it from
| costs and trade-offs and lets you decide. That's a legitimate
| mode of technical discourse. Contrast with someone claiming
| "studies show" functional programming reduces defects by 40%,
| citing one paper with n=12 undergraduates. The second is
| worse, and it's worse specifically because it's pretending to
| be scientific while the first isn't. I think the solution is
| not to make the field more rigorous and more scientific and
| require solid peer-reviewing of every idea. It's making the
| field more honest about the kind of claims we make.
|
| Clojure remains hard sell to beginners because they haven't
| suffered enough yet. Experienced engineers get excited about
| immutable data because they've spent nights debugging race
| conditions. They appreciate simple functions-and-data because
| they've been lost in a tangled class hierarchy. The language
| solves problems they've actually had. Junior devs haven't hit
| those walls yet, so the solutions feel pointless. Why would
| you care about a painkiller if nothing hurts?
| uxcolumbo wrote:
| Thanks for sharing your thoughts. Haven't seen it from that
| perspective yet.
|
| But then you have companies like NuBank, who chose
| Datatomic / Clojure and trains new devs in it.
|
| So it's about tech leadership with a 'nobody got fired for
| choosing IBM' mindset not wanting to take risks. Go with
| the 'safe' option... Python, TS, etc and their respective
| ecosystems and developer pools.
|
| Or is the reality that Clojure put you ahead back in the
| 2010s, but in 2026 it only offers marginal business value
| and benefits.
|
| Anyway, I'm a newbie and am continuing to learn it because
| I want to learn to think differently about software
| architecture.
| zerr wrote:
| Interesting, how many ex-users of Clojure are in the comments.
| Everyone is praising it, but also everyone moved to something
| else?
| moomin wrote:
| It's a real statistical outlier, nearly every language people
| have moved on from gets negative reviews. Me, it was fun but it
| wasn't for me and eventually I concluded a number of the
| fundamental design decisions were wrong.
| uxcolumbo wrote:
| Can elaborate which design decisions were wrong and why in
| your view?
___________________________________________________________________
(page generated 2026-04-17 23:01 UTC)