Dan recently recorded a session about Relic, if you'd like to hear him speak more about the origins of the library, some design choices, and some examples:

https://youtube.com/watch?v=QsEJ5O2e4Es

If you have an hour spare, probably the best way to understand Clojure's main selling points is to watch this talk: https://www.infoq.com/presentations/Simple-Made-Easy/

InfoQ list the Key Takeaways as:

- We should aim for simplicity because simplicity is a prerequisite for reliability.

- Simple is often erroneously mistaken for easy. "Easy" means "to be at hand", "to be approachable". "Simple" is the opposite of "complex" which means "being intertwined", "being tied together". Simple != easy.

- What matters in software is: does the software do what is supposed to do? Is it of high quality? Can we rely on it? Can problems be fixed along the way? Can requirements change over time? The answers to these questions is what matters in writing software not the look and feel of the experience writing the code or the cultural implications of it.

- The benefits of simplicity are: ease of understanding, ease of change, ease of debugging, flexibility.

- Complex constructs: State, Object, Methods, Syntax, Inheritance, Switch/matching, Vars, Imperative loops, Actors, ORM, Conditionals.

- Simple constructs: Values, Functions, Namespaces, Data, Polymorphism, Managed refs, Set functions, Queues, Declarative data manipulation, Rules, Consistency.

- Build simple systems by: Abstracting (design by answering questions related to what, who, when, where, why, and how); Choosing constructs that generate simple artifacts; Simplifying by encapsulation.

So Clojure is a language that embodies these principles in its design. It's a Lisp, which means that all code is constructed from a very regular expression syntax that has an inherent simplicity and can be quickly understood. It's a functional programming language that provides exceptional tools for minimising mutating state, and it favours working with a small set of data structures and provides a core api with many useful functions that operate on them.

I'd say the result is getting a lot done with a small amount of code, minimal ceremony, true reuse, and the ability to maintain simplicity even as your system's capabilities grow.

There's also transcripts of this and other Rich Hickey talks available: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

If you plan on creating your own radar, or you're just interested in how we went about it, there's also a blog post about the process at https://www.juxt.pro/blog/radar-2021.

You're also welcome to use our ClojureScript Radar graphic at https://github.com/juxt/radar.

strongarmtech.com?

"I guess there's no way of knowing, but I really would like to find out..."

Yes, so would I, which is why I followed the link to this article after reading the title!

So in other words:

983 billion, billion, billion, billion, billion

If every human that ever lived had made a thousand git commits every second of their lives to the same git repository, we would still expect no collisions.