I personally would want to use an immutable functional language wherever I can and only not use it if I have a good reason not too. Immutability makes reasoning about programs significantly easier, especially if they rely on concurrency.

And for finance it particular it's a very natural fit because there's just a lot of transformation of data and business logic.

So, how does immutability matter if we deal with the database -- which is what holds the state, and is obviously mutable.

Datomic is immutable in the sense that what you had for lunch today doesn't change what you had for lunch yesterday, where "lunch" is any arbitrary fact stored in the database.

I.e., you can ask to look at the entire database as it was yesterday, and run arbitrary queries against it.

You can also do speculative updates to it, in the sense of "show me the entire database as it would be if I were to have pizza for lunch".

It models this as a strictly linear succession of assertions and retractions of facts. Yesterday, `A` was true, today `A` is no longer true. While this new fact is recorded, it doesn't change the fact that yesterday, `A` was true.

Sounds great in theory.

What we see in reality is that append-only database is unusable without making additional "projections" or whatever you call them, databases that are ready to be queried/updated, with maybe specific denormalizations, indexes and so on.

And oh, btw, those later databases are not "imutable".

It’s structured so that these operations can be done pretty much instantaneously. Schema is sort of asserted at read time, not write time.

I highly recommend the talk “Domain modeling and with Datalog”[1]. It gives an explanation of how all this works, including indexing.

1: https://youtu.be/oo-7mN9WXTw

Dstomic is an immutable log (kind of like git). the only operation is append. there is a head pointer stored pointing to “latest”, this is the point of mutation you’re looking for, and it’s the only point.

Lots and lots of ETLs. Functional languages are a great match for that class of problem.

There are a lot of different kinds of financial institutions with a lot of different kinds of needs. In general, however, functional languages are a good fit for highly regulated domains, because they encourage splitting the (stateless) business legal rules for the domain from the stateful data management.

Complecting the two into, e.g. an Account object that has both metadata related to an account and e.g. rules related to transactions that can be part of an account quickly turns into an expensive maintenance nightmare.