Kind of vague. What exactly are you looking for?

All content that I found was just The oficial doc or some questions on Stack overflow. I'm trying to use them, but always there is something that I do not know how to do. So, I would like to read more about it. Maybe some articles with examples, or some repos that uses does features

https://clojurians.slack.com/archives/C1AC4BU2K/p1691788518760539?thread_ts=1691717298.535829&cid=C1AC4BU2K

Feel free to ask specific questions about those features, or ask for help when you get stuck. I suspect there's not a huge amount of material out there about them because they're not all that widely used? They're features that you use when you have to as part of specific Java interop situations...

For perspective, (1) use whichever is simplest, and don't forget the possibility of using a true Java class... there is no "king's road to Java platform interoperability"; and (2) Clojure's proxy can be considered in the context of alternatives in more or less the same space, including https://github.com/redplanetlabs/proxy-plus and Java's own Proxy

I have never dealt with gen-class and proxy myself but this article helped me understand what is available https://cemerick.com/blog/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form.html

Proxy should mostly be used for backwards compatibility with Java code. It's very easy to use if you know java. If proxy works for your usecase go for it - but be aware that there is some performance overhead to it if you are going to make millions of calls per second to a proxy.

This flow chart is classic and very helpful: https://stackoverflow.com/a/7145488

I'd imagine some contributors to this assertion are the immutability (collections don't change, they create new, so it's handy to have both/multiple versions) and metadata (ability to put sources or flags or whatever on a piece of data without changing the value of the data)

I guess it's mostly related to immutability

> a good fit for financial services My thoughts, having used Clojure in Financial Services myself: • Many banks are extensively using JVM and have tonnes of libraries and internal services using JVM - so Clojure is compatible with it. • Clojure is also it's really fast (basically as fast as Java) which is multiple times faster than something like Python or Ruby. • Functional is easier to test than highly stateful Object Oriented code.

Rereadable serialization (pr-str and EDN) too. Imagine, one fine day, the need arises and someone opens up the log. What do they see there? And how well can it be demonstrated that the log represents what the software did? Clojure is helpful with both of those matters. Clojure's fine points (some enumerated above) make it well suited to https://martinfowler.com/bliki/CQRS.html and the pattern (the "https://www.digitalocean.com/community/tutorials/command-design-pattern" of CQRS) wherein a user's request is represented as a unit of data, which Clojure can serialize and read back in again. A program that receives user inputs, represents them as data, serializes the data to a log, and executes the log, is inherent notational assurance that the user's gestures were logged no less fully than they were executed.

It should be double colons.

Aha that’s fixed it. Cheers

To my knowledge the most scholarly/academic source is probably Rich Hickey's "History of Clojure" paper: https://dl.acm.org/doi/pdf/10.1145/3386321

any paper about lisp should also overlap with clojure. lisp is pretty old, it should have a bunch of papers.

https://github.com/papers-we-love/papers-we-love/blob/main/design/out-of-the-tar-pit.pdf

https://baishakhir.github.io/uploads/fse2014-lang_study.pdf > The languages Clojure, Haskell, Ruby, and Scala, all have negative coefficients implying that these languages are less likely than the average to result in defect fixing commits. > > The regression also suggests that projects written in Clojure is less likely to introduce a security error than average

Skimmed through the article - doesn't seem like there were any attempts to take "seniority" of the users of a language into account. No clue how something like that could be done but they don't even acknowledge it. Problematic because IIRC in SO surveys Clojure users are heavily skewed towards having years and years of experience.

Broaden sights a little, and you'll find that much (most?) that's been written about X discusses things that consume your time and discipline in X but not in Clojure. Take, for example, "Effective Java" and "Java Concurrency in Practice." All that stuff is intense tradecraft to the Java practitioner, but Clojure put it in a bottle and we can spend our time on the mission. Another example: "Scala for the Impatient". Hilarious book -- if you come from Clojure. So, in a nutshell, there could be an empirical measure whereby the goodness of X is inversely related to the number of "best practices" that tax the attention of practitioners of X.