equality of hash does not ensure equality of the datastructures that being said you can try this lib: https://github.com/replikativ/hasch

Two identical things should produce the same hash, so they should be equal, right? I understand that a collision with another structure can occur, but for my case, it should be okay. Hasch solves the inconsistency only partially, numbers like 1.44e25 still have a different result (makes sense, the solution I’m looking for must be quite opinionated as some compromises on numbers must be done to compare them)

I would not be surprised if many/most ways of printing floating point values do not result in identical bit pattern representations on another system after printing & reading the printed representation.

A collision with an unlimited of other structures can occur with hashes, not just a few.

If you calculate something like a SHA-256 hash, then the likelihood of a collisions drops so dramatically that in practice you can say "hash equal almost certainly implies structure equal"

using equality on doubles is rarely what you want, so the same goes for hashes

I planned to solve it by converting the numbers to the same string representation in both systems before hashing it. But of course this brings other problems (and loss of precision).

I have not tried that before, but I would not be surprised if you are in for a world of frustration attempting to do that for floating point values.

So i was able to create consistent num->string conversion in both environments if i stay in limits of JS numbers. I am going to create some test with malli generators to see how many collision i will be able to get (using native hash - murmur3) 🙂

Don't use Spec for data coercion/conversion. Don't use records unless you a) need to participate in type-based dispatch and/or b) you've proved via profiling that you have a bottleneck that would be addressed by switching hash maps to records 🙂 I don't know if there are specific articles about this sort of stuff (there probably are but I've no idea how/where to look). A lot of this is sort of "tribal knowledge" that is picked up over time, interacting with the community. I'll be interested to hear what others suggest here...

Alessandra's list of do's and dont's is worth a read if you haven't seen it: https://stuartsierra.com/tag/dos-and-donts but my personal favourite is "don't mix side effects with lazyness". I often reached for doall when I was starting out in clojure and now I find I rarely use it at all.

I think it's also worth remembering that mulitmethods and protocols are extensible versions of cond/`case`/etc. Start simple with a function that calls cond and reach for the more powerful constructs when you find out that you need them.

hah! I think data coercion might be ALL my org tried using spec for 🙂

Thanks everyone! I was hoping for a larger list of don'ts but it sounds like asking about specific items one at a time is the best approach to go forward on it. I think it would be great to compile this sort of thing into a published list somewhere to help relative newcomers avoid common pitfalls and reduce negative experiences. Alessandra's article is a good one that I've read a few times before - maybe it's even what inspired my question. Thanks again.