Thanks for the reference. I agree with the rant word by word.
I use
tcache. It is a cache with access and update in the STM monad and each element can have its own persistence, defined by the programmer. So an element can be the result of a web service request for example from AWS, another from a database and a third from anywhere. the three can participate in the same STM transaction in memory and update their respective storages, if they are modified.
These are the kinds of things are not possible in conventional databases. It is easy to create a almost a perfect product if you establishes the rules of perfection and you sit at the center of the development process that is what the SQL databases did for a long time. The DBs stayed at the protective womb of the back-office, with a few queries per second and being consistent with themselves and with nothing else. Now things have changed. We need their STM transactions working for us close to fresh application data at full speed, not in the backoffice. We need our data spread across different locations. We have no other option. We need to synchronize and integrate more than ever, so we need software and developers that can figure out what the data is about by looking at it, so the schema must be implicit in the data and so on.