Biometrics, heart rate and sleep tracking are huge, like 95% of the reason I own a smart watch. It's a sensor, not a UI. Everything else can be done better on a phone.
I turn off notifications (because if I get a message on my watch, what am I going to do with it? watch is basically read-only)
One use that comes up a lot: setting a timer. Being able to ad hoc set timers with your voice is huge - without it, my coffee would get cold, my laundry would stay wet, and my kid would be late because dad got distracted by a HN comment.
1) Clojure is stable and there will never be big news or big changes to the core language. It's simple in the objective sense. There's fewer patterns to learn, hence less to talk about online. The code I wrote 12 years ago still works. The books I bought 12 years ago are still relevant. To an amateur github star gazer looking only at the metrics from the past month, this looks like stagnation. To me, this looks like good engineering.
2) The can-do pragmatic attitude meshes very well with entrepreneurs and small teams writing proprietary applications that need to get things done. These are NOT the people evangelizing and marketing open source tools. Clojure's successes are private, small, and quiet. In general, there is little to no focus on external validation.
3) Clojure is unabashedly a tool for experts. Don't get me wrong, the community is amazingly welcoming to newbies (as I discovered). But in order to align with Clojure's value proposition, you need to understand the problems it solves and feel them deep in your bones. If the words "mutable state" mean nothing to you, Clojure is going to feel wierd.
These conspire to make Clojure less visible online. Clojure's core audience, expert programmers who focus on outcomes and stable code, they do not read or write SEO blog spam.
The trending technologies, those that change so much they require articles like "How to do X in Y in April 2026" are built on shaky foundations. Trending means churning. That's hardly a value worth chasing.
Since NUBank literally built a billion dollar business because of Clojure, I would have thought the adoption in fintech at least would have been bigger.
Maybe it's because CTOs are just not sure and feel safer for adopting a 'nobody got fired for choosing IBM' mindset.
Maybe it's not important that Clojure needs to grow its ecosystem.
And consequently the company needs to continue building its own adapters and SDKs to use existing commercial and open-source solutions (e.g. in data and observability), because Clojure and Datomic are almost never supported out of the box by any tools. That's a cost added that may not always be justified, because anything related to Clojure and/or Datomic is going to require bespoke integrations.
Not to mention that hiring is a problem because the Clojure market is relatively small. But that's not the reason the language never caught on. Perhaps only a reason companies rarely choose it.
> And consequently the company needs to continue building its own adapters and SDKs to use existing commercial and open-source solutions (e.g. in data and observability), because Clojure and Datomic are almost never supported out of the box by any tools.
But Java almost certainly is. Why not just use the Java stuff? All of the Clojure I've worked on (especially in the data space) has made use of a ton of Java SDKs and libraries.
As I tried to explain above, Clojure is made for a specific set of problems. Your problem seems to be interop with the SDK of the month and hiring. My problem is mutable state. It's logical that we'd choose different solutions.
A pure Clojure stack is extremely rare in most organizations. And integrating data from microservices with data lakes and observability platforms is not "SDKs of the month" but a normal business concern.
What I am trying to say is that immutable state may be one aspect of something much larger that did not factor into Nubank's original decision to use Clojure for microservices. It may have clear benefits there (and in your case - I don't deny that), but downstream you pay for that rarity by having to build every integration yourself.
Hidden 13 paragraphs down the third page is the first actual description of the project:
> So FSet has a dual mission: first, to bring Common Lisp up to date, by giving it a much richer ensemble of functional collection data structures, to greatly expand the space of algorithms that can be written in an elegant functional style and still run efficiently; and second, as with Clojure, to support and encourage the use of functional collections for general programming.
Cool project but the docs could be greatly improved by putting the purpose of the project front and center. Don't make readers guess.
Not OP but it looks great! Your humility is much appreciated. I am excited for the Lisp community, and will follow this approach to CL as I do with Jank's approach to Clojure.
If you ask a vague ignorant question, you get back authoritative summaries. If you make specific request, each statement is taken literally. The quality of the answer depends on the quality of the question.
And I'm not using "quality" to mean good/bad. I mean literally qualitative, not quantifiable. Tone. Affect. Personality. Whatever you call it. Your input tokens shape the pattern of the output tokens. It's a model of human language, is that really so surprising?
Assembly theory approaches the question from a different angle but largely reinforces this conclusion. Essentially, anything past a significant level of chemical complexity is a sign of life. DNA is astronomically unlikely to form spontaneously. It was designed by co-evolution. If you find a screwdriver on an alien planet, you can deduce the existence of screws, machines that require fasteners, and ultimately a living being that built those machines.
In the history of the universe, we only know of a single instance where something ejected from planetary atmosphere by its own force. Humans, when we launched a rocket into space. That's it. Debris enters planets atmosphere but we never see a rock LEAVING an alien planet on its own power. Except on earth.
A planetary system with evidence of panspermia would be a similar phenomenon to DNA, a screwdriver, or a rocket - clear evidence that life was at work to produce something otherwise so implausible.
This works so well as a framework for finding alien life since it makes no assumptions about what life is or what it consists of. Only that it produces complexity.
> If you find a screwdriver on an alien planet, you can deduce the existence of screws, machines that require fasteners, and ultimately a living being that built those machines.
"Hey, Bob! Here's the screwdriver we lost yesterday."
(Or close enough. From one of Arthur C. Clark's SF humor stories?)
I turn off notifications (because if I get a message on my watch, what am I going to do with it? watch is basically read-only)
One use that comes up a lot: setting a timer. Being able to ad hoc set timers with your voice is huge - without it, my coffee would get cold, my laundry would stay wet, and my kid would be late because dad got distracted by a HN comment.
reply