Orthogonal Persistence
github.com
Orthogonal Persistence
1–10 of 38 posts
Re: Orthogonal Persistence
#2having this as a model would be lovely and I agree wholeheartedly with the exposition. its interesting though to think about what impact this model would have on programming. a lot of our processing and tooling are built around the notion that programs are _almost_ right, and that we can bring them in and out - and hopefully in the process our precious data hasn't been mangled.
when we express state directly in programs, we gain a lot, but our notion of trashy disposable execution goes away and now we have to think a lot more about how that system evolves.
Re: Orthogonal Persistence
#3Yes, we can absolutely implement this but your computer now runs x times slower and or is y times more expensive. For the vast majority of people, this would be a quaint exercise and real market exists for it.
Re: Orthogonal Persistence
#4having this as a model would be lovely and I agree wholeheartedly with the exposition. its interesting though to think about what impact this model would have on programming. a lot of our processing and tooling are built around the notion that programs are _almost_ right, and that we can bring them in and out - and hopefully in the process our precious data hasn't been mangled. when we express state directly in progr…
Reminds me of the discussions on hn when Intel Optane wasn't quite dead yet. Those always seemed to end with the conclusion that if separation between volatile and persistent memory had not been forced on us by technological reality, it would be a concept we'd better have invented at some point.
Re: Orthogonal Persistence
#5having this as a model would be lovely and I agree wholeheartedly with the exposition. its interesting though to think about what impact this model would have on programming. a lot of our processing and tooling are built around the notion that programs are _almost_ right, and that we can bring them in and out - and hopefully in the process our precious data hasn't been mangled. when we express state directly in progr…
Reminds me of the discussions on hn when Intel Optane wasn't quite dead yet. Those always seemed to end with the conclusion that if separation between volatile and persistent memory had not been forced on us by technological reality, it would be a concept we'd better have invented at some point.
Think you can find any of those discussions? I'd be curious to read/browse.
Re: Orthogonal Persistence
#6> Transactions are not modular because every function needs to know whether it’s already in a transaction or not, to be conscious of what global entry point in a completely different module owns the transaction.
I fail to understand the section about why transactions are unmodular. I've never encountered transaction code where the initiator of the transaction would affect the computation; could anyone elucidate this?
Re: Orthogonal Persistence
#7> Persistence is Orthogonal to the Data Model, ...
I have some experience with a custom data runtime where the persistence is orthogonal to the data model, with silhouettes reminiscent of the described solutions in many of the features of my system, including multiple orthogonal/model-agnostic persistence backends, automatic data synchronisation, persistable executions, automatable schema changes, automatic reactivity.
This direction can indeed bring about great savings in various parts of development; however, it seems to me that more subtlety than indicated in the post is required.
The programmer must be provided with ergonomic means to give denotations for things like when and where to persist, in order to reduce data movement, and to keep the system performant (this does not violate orthogonality; we may specify e.g. to persist at the logical location, say, in the cloud, without having to specify the physical persistence). For instance, considering the case of schema changes, unless the system bundles its language inside the database, for performance sake, to perform such changes in an "Orthogonal Persistence" system external to the database would take an completely disproportionate amount of time relative to using SQL in the database. The data runtime I work with uses the idea of lenses (where valid lenses would necessarily be reversible) to allow for coherent, undoable schema changes, but I still resort to SQL for regular (eager) migrations (the lenses system for schema changes can still be useful for migrations applied lazily).
Re: Orthogonal Persistence
#8Earlier quoted context omitted.
Reminds me of the discussions on hn when Intel Optane wasn't quite dead yet. Those always seemed to end with the conclusion that if separation between volatile and persistent memory had not been forced on us by technological reality, it would be a concept we'd better have invented at some point.
Think you can find any of those discussions? I'd be curious to read/browse.
This is the one that was featured in my memory:
https://news.ycombinator.com/item?id=32314814
But the most recent one is also interesting: https://news.ycombinator.com/item?id=38527437
Re: Orthogonal Persistence
#9having this as a model would be lovely and I agree wholeheartedly with the exposition. its interesting though to think about what impact this model would have on programming. a lot of our processing and tooling are built around the notion that programs are _almost_ right, and that we can bring them in and out - and hopefully in the process our precious data hasn't been mangled. when we express state directly in progr…
Reminds me of the discussions on hn when Intel Optane wasn't quite dead yet. Those always seemed to end with the conclusion that if separation between volatile and persistent memory had not been forced on us by technological reality, it would be a concept we'd better have invented at some point.
I was tangentially involved with an orthogonally persistent OS, and we indeed had had to reinvent a distinct journalling channel and special optionally-volatile storage, for DBMS-style applications.
Re: Orthogonal Persistence
#10See the end for a discussion of "Unfriendly Persistence": https://github.com/mighty-gerbils/gerbil-persist/blob/master...
(the data you'd like to keep is more volatile than you'd wish, but the data others keep on you is much less volatile that you'd wish)