https://micrometer.io/ this one is a good option as a generic metric library with options how to export numbers to various frontends like prometheus

Take a look in #C010TGGL02X

(-> (java.util.Date.) clojure.reflect/reflect :members
      (->> (filter #(-> % :name (= 'getMillisOf)))))
=>
(#clojure.reflect.Method{:name getMillisOf,
                         :return-type long,
                         :declaring-class java.util.Date,
                         :parameter-types [java.util.Date],
                         :exception-types [],
                         :flags #{:static :final}})

am I misunderstanding that a public final method can be called like that?

getMillisOf is not public.

If you don't care that normalize can be called on that inst, you can just call its getTime member fn.

ah, it's just static, sorry, thanks!

why not just (.getTime #inst "2000")?

https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#getTime--

because I had no experience with the JDK before learning Clojure 10 yrs ago and even since then I'm trying avoid learning the historical, deprecated classes, so I'm primarily using the java.time package.

also, i just looked at the JDK sources and getMillisOf was the method, which was returning the fastTime instance variable, so it looked like just what I needed.

definitely better to use the java.time things, much more useful

Instant has a toEpochMilli fn, and things are generally convertible to Instant (just might require adding a timezone in case you are working with LocalDateTime or so)

i just wanted to check something using d/as-of and wanted to add a single millisecond to #inst "2000", so i thought i would learn how to do that using the java.util.Date API, but i should have just put up with the verbosity, do the round-trip to Instant and don't disturb people here 🙂

What's d/as-of?

https://docs.datomic.com/cloud/time/filters.html#as-of

unfortunately Datomic is still using java.util.Date...

wasteful, but maybe just always convert to bigint? (defn bit-shift-left' [x n] (.shiftLeft (java.math.BigInteger/valueOf x) n))

Yeah, I'm starting to write a small collection of functions that I want, which use java.math.BigInteger operations, but also accept long or clojure.lang.BigInt operands, so there are a few more cases to handle.

ref is required when you need coordinated updates across two separate sources. Think: database transactions where you are updating multiple tables. They are very rarely used in Clojure because most "atomic" data can be handled by an atom.

can you give me an actual use case for ref? because I think that by using a compound atom you can overcome the necessity of having multiple refs. I'm trying to understand why clojure introduce this different entity that has a different API. switching between the two is not an easy refactor task

If you combine multiple values under the same atom, you can't un-combine them.

I guess you can almost always track all your mutable state with a single reference like an atom, but this is not always the best idea. First from a design POV. If you have state that is mostly independent, smashing it together in one atom is weird, and not always possible, like when you have different modules of the project tracking it's own state. For this you can create multiple atoms, but if you also want to be able to modify them in a transaction some times, refs are the thing. And there is also the perf aspect. If you smash everything together in the same atom where most of the time sub-state will evolve independently, then multiple threads will be unnecessarily competing for changing the same atom, which could make your CAS functions be re-run a lot.

Refs implement STM, and I think could potentially be sped up at hardware level (modern CPUs have some crazy capabilities in that regard). Hardware accelerated or not, STM allows for more concurrency, which is a bit of a stretch — one can do an incredible amount of updates on a single atom as well.

Data split up across many ref's gives at least the possibility that many threads/CPU cores could achieve higher throughput with increased paralleism of processing, if the average "conflict rate" on indiivdual refs remains low. That is as compared to a single atom, where it is guaranteed that any two threads wanting to update its value at the same time will cause one of them to wait.

But there is definitely an additional burden on a developer to ensure that such parallel updates to distinct sets of ref's leads to no mangling of the consistentcy of the overall data being kept in them.

I had to use ref recently to handle having one thread reading output from tcpdump and another thread pulling out that output for visualization purposes. Maybe someday I'll re-write it with core.async 😉

thanks for all your replies. so I understand the use case of refs now better, and I want to change my question, what are the benefits of atom? when should I use atom over ref? If I want parallelism and transaction I should go for refs, but once again, refactoring an atom to ref may be expensive, so why not using a ref in the first place?

I can only say that in nearly 13 years of production Clojure, and working with 140k lines of Clojure right now, I've never needed to use a ref. I use atom quite a lot. In the data and domain I work with, I don't tend to have in-memory coordinated mutation of multiple data sources. I have transactions for the relational database I work with because that sort of coordinated mutation across multiple tables crops up from time to time. I have in-memory coordinated mutation of individual data sources, but not for multiple data sources.

I understand, but by design, why can't we transact on multiple atoms? why did clojure introduce a new state concept of ref just for this purpose?

My understanding of the history is that Rich thought at the time that STM and refs would be much more widely useful than they've turned out to be in practice.

From Rich's "History of Clojure" paper (my emphasis): 3.6.5 Summary. Taking on the design and implementation of an STM was a lot to add atop designing a programming language. In practice, the STM is rarely needed or used. It is quite common for Clojure programs to use only atoms for state, and even then only one or a handful of atoms in an entire program. But when a program needs coordinated state it really needs it, and without the STM I did not think Clojure would be fully practical.

My advice is: user atoms and then if you have a situation where you discover you really need refs, refactor to use them. The reality is you'll probably never need them.

atom is just a wrapper over Java's AtomicReference , so it was already there, and is conceptually very simple. STM involves refs but also works correctly with agents, it is quite complicated and, like many have said above, almost never used. You can safely forget about the existence of ref s and you'll be fine.