Clojure: The Documentary, official trailer [video] • Hacker News Board

Re: Clojure: The Documentary, official trailer [video]

#91

Post by joshlemer » Thu, Apr 02, 2026, 3:39 PM UTC

midnight_eclair wrote: post #89

Capricorn2481 wrote: post #86

Earlier quoted context omitted.

I don't disagree with what you're saying. But by "onboarding process" I mean the effort of getting more people into Clojure, not the experience for a single person. 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 un…

> the original person suggested it's not popular because it doesn't have one, and I just don't think that's true 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 mu…

Yeah, Elixir's Pheonix if anything demonstrates how important a flagship framework/stack plays a huge role in driving language adoption. Despite Elixir coming out after Clojure, and running on a VM that is more esoteric/niche than the JVM, and having a host language which is 1000 times smaller in popularity and library ecosystem size, it still is probably more popular than Clojure at this point and almost all of that is from people picking up Elixir to use Pheonix. And Clojure's use is not just staying where it is, it seems to be in free fall. There used to be dozens of Clojure job postings in Canada, now without exaggeration I don't think there's a single one.

Re: Clojure: The Documentary, official trailer [video]

#92

Post by agency » Fri, Apr 03, 2026, 1:27 AM UTC

puredanger wrote: post #84

agency wrote: post #58

Earlier quoted context omitted.

Simple Made Easy[ https://www.infoq.com/presentations/Simple-Made-Easy/ ] in particular had a huge impact on the way I think about writing software at a formative time in my development/career. I have not had the chance to use Clojure professionally, but thinking about software in terms of "intertwining" is the idea I return to when evaluating software designs, regardless of technology, and gave me a way to articulat…

FYI, the canonical version (recut slides / video / audio) of this talk can now be found at https://www.youtube.com/watch?v=SxdOUGdseq4

I always wondered what that juggling animation slide looked like!

Re: Clojure: The Documentary, official trailer [video]

#93

Post by waffletower » Thu, Apr 09, 2026, 6:17 PM UTC

jwr wrote: post #77

waffletower wrote: post #68

Earlier quoted context omitted.

There were multiple reasons at our company -- my particular team, all skilled Clojurists, decided to default to python last year for a variety of reasons including both AI code generation suitability and AI model utilization in our code bases; the latter is of high relevance for our particular work. While I find Clojure to be among the best languages for interacting with LLMs via API, it is awkward for interacting wi…

> AI code generation 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.

I agree -- all modern frontier models I have tested generate Clojure very well.

Re: Clojure: The Documentary, official trailer [video]

#94

Post by acestus5 » Mon, Apr 13, 2026, 3:12 PM UTC

waffletower wrote: post #53

abeppu wrote: post #42

Earlier quoted context omitted.

I worked for a startup that used clojure and found it so frustrating because, following the idiomatic style, pathways passed maps around, added keys to maps, etc. For any definition which received some such map, you had to read the whole pathway to understand what was expected to be in it (and therefore how you could call it, modify it, etc). I think the thing is that yes, `[a] -> [a]` tells you relatively little abo…

I think the pipeline paradigm you speak of is powerful, and some of the clarity issues you claim can be improved through clear and consistent use of keyword destructuring in function signatures. Also by using function naming conventions ('add-service-handle' etc.) and grouping functions in threading forms which have additive dependencies, can also address these frustrations.

this is the new standard in hyperscale. Even Microsoft is doing Medallion architecture in Fabric.

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.