[socksy]

I love immutability and Datomic as much as the next Clojure programmer. But this sounds quite a lot like post-hoc reasoning.

For example, there's quite a few situations where you require mutability in bank data (e.g. with government requirements, or when you want to rollback fraudulent trading). Sure, both are solvable with Datomic, but they don't scream "huge advantage with an immutable datastore".

And there are plenty of highly competitive industries where code quality matters, but they're not flocking to functional programming.

Don't get me wrong, I think functional programming is an absolutely great way to structure and think about programming (and have coded professionally in Clojure for the last 5 years or so). But I suspect the prevalence of FP in some industries is as much chance/social reasons than it is for some inherit superiority in the approach.

[polityagent]

small note: Banks do not want to forget fraud, the rollback would be akin to a git revert. Even if the history presented to the customer makes the fraud vanish it won't be forgotten by the bank.

With government requirements I'm assuming you mean something like gdpr. Datomic supports actually removing data via excision. it's just not the default behaviour. I personally prefer a system that doesn't forget by default whilst preserving the option to do so.

you can also support destruction of personal data via other means such as key shredding.

[galkk]

Aren’t “rollbacks” done as separate transactions, that return account amount to Previous value?

[socksy]

Depends on the legal requirements of that rollback