A History of Clojure (2020) [pdf] | Hacker News Reader

A History of Clojure (2020) [pdf]

download.clojure.org

134 pointsndr42 comments

Also relevant, Rich Hickey listed the books that inspired him to create Clojure in his own Amazon account: https://www.amazon.com/ideas/amzn1.account.AFAABBRGIVOWVKTHP...

Easier to browse list: https://www.goodreads.com/list/show/137472.Rich_Hickey_s_Clo...

I find it interesting he includes Mozart/Oz (CTM). It'd be great to see more ideas from that language coming to Clojure.

Also Norvig's AIMA. Clojure could be well positioned for neuro-symbolic AI. That's somehow connected to Anglican, discussed in the History of Clojure article.

The Goodreads list has "Programming Clojure by Stuart Halloway", I guess it's an error or included more as an introduction to Clojure?

This book was written before Clojure was released as 1.0. (1.0 and Programming Clojure were released together!) Stu and Rich worked closely at that point. The process of writing the book and Stu were influential on Clojure.

Has Anglican been used in any significant project?

It looks interesting (though tbh I barely understand what it does.. it's borderline technobable to me) but I haven't been able to find it used anywhere on Github. It's also gotten zero updates since 2018

Doesn't mean it's not a hidden gem... I would have said something similar about Missionary as well

I think the main outcome from Anglican was a great theoretical textbook: https://arxiv.org/abs/1809.10756

But it is probably too expressive, and therefore too slow, for most practical inference problems.

Funny that it includes Instructor's Manual for SICP but not SICP itself. I wonder if anyone has read it (the manual), is it good? Seems it is not available online.

I think it's suitable for people who are trying to work through SICP by themselves, it contains some discussions and extra exercises that could be helpful in that scenario. Otherwise I think it's just like a small addition and won't vastly shape your experience with SICP, the main content is in the main book :)

Funny that it includes the hammock :)

I’m seeing a lot about clojure language, especially recently. I’m missing an insight into the clojure community, especially in the context of libraries and job market.

E.g. I’m not aware of any large framework like Rails or Phoenix. Is this something that is missing and yet-to-come, or there is no need for that?

How does this affect job search, are Clojure jobs less about SAAS/CRUD apps? Does each place build their own custom tooling?

There is no dominant over-arching framework like in some other languages. There are many smaller ones, with different approaches, so there is more choice.

As for SaaS apps, Clojure is a really good fit, because of ClojureScript. You can have a large part of your code as .cljc files, and compile both to JVM and to JavaScript in the browser. I found this is an incredible advantage, enabling a single founder like me to write and maintain a complex SaaS.

So like Blazor for C#?

It runs as quite lean JS on the frontend. If I’m not mistaken, Blazor targets WASM with huge binaries that may prevent its use in certain cases.

Not really specially after .NET 8, Blazor will be unifying all ASP.NET programming models, whereas in Clojure it is more simple.

Also ClojureScript doesn't do WebAssembly.

> Also ClojureScript doesn't do WebAssembly.

It's a bit ambiguous what you mean with "do", but you can definitely use WebAssembly modules in ClojureScript just like you can in JavaScript.

I'm not familiar with Blazor or C# so maybe I'm missing something obvious here.

The obvious part is compiling Clojure source code into WebAssembly bytecodes.

Ah, yeah, that's probably a bit far off in the future. Probably would be possible via GraalVM once GC is available, https://github.com/oracle/graal/issues/3391

please state the value prop of doing that?

That wasn't the question, rather comparing ClojureScript vs Blazor from OP.

I don't know Blazor, and it's difficult to tell from the webpage.

But I can tell you that most of my model (business logic) code is written in Clojure and compiles to both JVM and ClojureScript. In other words, I use the same code on the server and on the client. I also use EDN (meaning Clojure) as the serialization format between them, so I avoid serializing to something non-native. All this buys a lot of incremental improvement.

ClojureScript gets compiled using Google Closure compiler in "advanced" compilation mode — for those who might not know, this is not a "minifier", it's a whole-program transformer which does renaming and dead code elimination. The result is highly optimized JavaScript. I guess that's why there isn't much excitement about WebAssembly in Clojure circles — the current state of affairs is really good enough. In my experience (complex SaaS app), DOM operations are a performance bottleneck, not ClojureScript.

It sucks so no one uses it :)

I think Clojure had a moment 2015 to 2020ish, but it's passed. People still use it, even though it sucks. What's not to love:

- Incredibly slow

- Hosted on the JVM, so you're going to be dealing with Java eventually

- No automatic tail call optimization because of the limitations of the JVM, so it feels like you're writing a mess of macros rather than real functional code

It's definitely not over. I got into it professionally in 2018, and have remained employed with it at three different companies. There's turmoil around it because startups use it with great success, but then as they want to scale they have a hard time finding enough devs to throw at their new ideas.

> - Incredibly slow

Huh? Clojure is one of the fastest dynamic languages. It's not intended to replace C++ or Rust.

> - Hosted on the JVM, so you're going to be dealing with Java eventually

In the real world this is a blessing since there are a lot of useful Java libraries out there.

> - No automatic tail call optimization because of the limitations of the JVM, so it feels like you're writing a mess of macros rather than real functional code

How did you come to this conclusion? Lack of automatic TCO doesn't mean you have to write macros, and most people in the Clojure community will tell you to prefer functions over macros unless it's absolutely necessary.

> - Incredibly slow

Almost as fast as Java, and for performance critic processes 99.9% of the time we bump on infrastructure performance problem BEFORE hitting the wall with Clojure (see https://clojure-goes-fast.com/blog/ for tips and tooling about performance)

> - Hosted on the JVM, so you're going to be dealing with Java eventually

For me it's a major selling point: JVM is battle tested and a wonder of engineering. The Java ecosystem richness is incredible (see tooling above for monitoring and profiling for an example). And the platform is constantly moving forward (see latest JDK with virtual threads, generational ZGC, etc.). And of course GraalVM... (https://www.graalvm.org)

> - No automatic tail call optimization because of the limitations of the JVM, so it feels like you're writing a mess of macros rather than real functional code

Never have been a problem and I don't see the point with macros, and code we write looks _very_ functional...

> JVM is battle tested and a wonder of engineering. The Java ecosystem richness is incredible (see tooling above for monitoring and profiling for an example).

This is all true.

That said, the way I can't help but feel is: keep that entire galaxy of insane bloat two and a half million miles away from me please. :p

You have (recur ,,,) for TCO.

Other replies have covered most of this.

However, I want to point out that sometimes Java can peak its head out. If you rely on Java tooling you will also likely need to have some idea of how Clojure implements things in Java.

So while Java gives us access to a great variety of tools and libraries, heavy reliance on the host can make things a bit more difficult, especially for new programmers.

Clojure users tend to prefer tiny libraries that excel at one task and compose them together. While Pedestal is definitely a framework, its eclipsed by the sheer popularity of Ring (HTTP abstraction library similar to Rack), where you roll with your own choice of web server, router, middleware, database, data validation and coercion, etc.

Got it. So there’s no missing library, just more flexibility and the community embraces that. Thanks for explaining!

Right. Instead of 4 frameworks competing, yet having mostly similar say 25 underlying functions, clojure has say 50 functions (assuming half the framework code overlaps between frameworks) as libraries that can be composed to achieve the same functionality as those frameworks, and more.

Yeah, Clojure basically takes one of the ideas from Alan J. Perlis' "Epigrams in programming" to the next level.

> 9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.

http://www.cs.yale.edu/homes/perlis-alan/quotes.html

Where generally the proverbial "one data structure" is a hash map.

"Just use a map" [0]

[0] https://www.youtube.com/watch?v=aSEQfqNYNAc

https://kit-clj.github.io

https://fulcro.fulcrologic.com

I haven’t really worked in closure for a while, but luminus was my go to web framework in the past.

https://luminusweb.com/

Luminus has a successor called Kit.

I worked with Clojure professionally, and one of the things it forced me to unlearn was reliance on frameworks and lots of little libraries for everything. It's just not necessary when your language is so expressive and simple.

I know nobody believes me when I say this, but I really mean it.

The Clojure's approach is to favour libraries over frameworks. We use Clojure on various style of applications (mainly web and API based), hosted on widespread infrastructure technologies of Cloud Providers (Kubernetes, PostgreSQL, Kafka, etc.) and it's a breeze: here are our reasons for choosing Clojure https://defsquare.com/blog/why-we-bet-on-clojure

If you want to look at libraries where some people have settled, here are our _opinionated_ takes on libraries that we use on almost every project:

- HTTP: Ring is the de facto way to manage HTTP request (see https://github.com/ring-clojure/ring/wiki/Concepts) supplemented with various "Middlewares" for web-related concerns (security, logging, content encoding, etc. see https://github.com/ring-clojure/ring/wiki/Standard-middlewar...). Jetty and Aleph are common web servers (and https://github.com/clj-commons/aleph) that implement Ring interface.

- Routing: Reitit (https://github.com/metosin/reitit)

- Single-Page App: shadow-cljs for the build concerns (https://github.com/thheller/shadow-cljs), Reagent with Re-frame for complex/large app (https://reagent-project.github.io and https://github.com/day8/re-frame). Even if we now prefer using HTMX (https://htmx.org) and server-side rendering (Hiccup way of manipulating HTML is just amazing, https://github.com/weavejester/hiccup).

- Schema management: Malli (https://github.com/metosin/malli)

- Lifecycle management: Mount, Integrant or Component (https://github.com/tolitius/mount https://github.com/weavejester/integrant and https://github.com/stuartsierra/component)

- Config management: Aero (https://github.com/juxt/aero) and environ (https://github.com/weavejester/environ)

- Log: μ/log (https://github.com/BrunoBonacci/mulog)

- Time: https://github.com/juxt/tick

- Testing: https://clojure.github.io/clojure/clojure.test-api.html and Kaocha for the runner (https://github.com/lambdaisland/kaocha).

- Package and project management: tools.deps is simple and powerful (https://clojure.org/guides/deps_and_cli)

For infrastructure stuff (PostgreSQL, Keycloak, Solr, Kafka, etc.), just wrapping the underlying Java library or driver is often enough, and there are lots of wrappers for easing the integration. And we implement Hexagonal architecture style to put all of that in place.

Don't be afraid a libraries not moving a lot recently, it's a sign that the library is mature and battle-tested. Clojure is a joy to use every day :)

Mentioning μ/log and no mention of timbre (https://github.com/taoensso/timbre), that is an odd omission. Malli is a great mention, but there ought to be a mention of clojure.spec (https://github.com/clojure/spec.alpha) which has much more mindshare.

Yes I agree, timbre and clojure.spec are great and I used them a lot, nowadays I move to μ/log and Malli for instance. My comment was to provide some guidance for someone outside of the Clojure community to navigate in the library ecosystem. I updated my comment to reflect that it's an opinionated take and just that.

Thought I'd seen everything from Rich but I somehow missed this. Thanks for sharing! I enjoyed the insight into his process rather than just the fully formed idea.

There's a talk I uploaded on youtube where Rich Hickey explains some history of clojure. https://youtu.be/nD-QHbRWcoM

I have never been a fan of Clojure or Lisp. But the YouTube talks by Rich are excellent. Worth watching even if you are not into Clojure or Lisp.

And writing your own Lisp in your favourite programming language is super fun btw. Highly recommended.

Reply on news.ycombinator.com