Add redux crate to isolate parts of `State` and `Instance` logic

[timotree3]

PR summary

Motivation: a lot of the tests in instance.rs have a lot of specific logic for the listener-thread and the DNA initialization process. Separating out this logic and making it generic upon State type facilitates the creation of simple and easy to verify tests.

I now have version one of the redux API set up. It will take a lot of work to integrate this API into the rest of the code-base. I'm making a draft PR in the meantime so I can get feedback on the crate design.

testing/benchmarking notes

None yet

followups

None yet

changelog

Please check one of the following, relating to the CHANGELOG-UNRELEASED.md

• [ ] this is a code change that effects some consumer (e.g. zome developers) of holochain core so it is added to the CHANGELOG-UNRELEASED.md (linked above), with the format - summary of change [PR#1234](https://github.com/holochain/holochain-rust/pull/1234)
• [x] this is not a code change, or doesn't effect anyone outside holochain core development

[StaticallyTypedAnxiety]

I think this could be beneficial, definitely opens the door to more deterministic tests, I had a idea of borrowing from the functional school but I think it wouldn't be a bad idea to introduce immutable data structures https://docs.rs/im/13.0.0/im/ , track our history then and eliminate some of the mutability,

That way we have pure redux loop.

What do you think?

[timotree3]

I had a idea of borrowing from the functional school but I think it wouldn't be a bad idea to introduce immutable data structures https://docs.rs/im/13.0.0/im/ , track our history then and eliminate some of the mutability,

That's an interesting idea. If we were committed to a reduce interface without mutability, I think that would definitely be the way to go. Something like this:

fn reduce(&self, &Self::Action) -> Self;

However I'm not so sure I want that interface. In my view, the goal of eliminating mutability, while very relevant in languages where it's easy to abuse it, like Javascript (the originator of the Redux pattern), isn't relevant in Rust. Even as the docs for that crate you linked say

While immutable data structures can be a game changer for other programming languages, the most obvious benefit - avoiding the accidental mutation of data - is already handled so well by Rust's type system that it's just not something a Rust programmer needs to worry about even when using data structures that would send a conscientious Clojure programmer into a panic.

[thedavidmeister]

does rust really remove all the problems of modelling identity and value, therefore making mutability somehow "obviously safe"?

(rust does handle mutability better than most things! i'm just not convinced we can't improve anything)

since they mention clojure programmers specifically, here is the writeup from the clojure docs https://clojure.org/about/state

While some programs are merely large functions, e.g. compilers or theorem provers, many others are not - they are more like working models, and as such need to support what I’ll refer to in this discussion as identity. By identity I mean a stable logical entity associated with a series of different values over time. Models need identity for the same reasons humans need identity - to represent the world. How could it work if identities like 'today' or 'America' had to represent a single constant value for all time? Note that by identities I don’t mean names (I call my mother Mom, but you wouldn’t).

So, for this discussion, an identity is an entity that has a state, which is its value at a point in time. And a value is something that doesn’t change. 42 doesn’t change. June 29th 2008 doesn’t change. Points don’t move, dates don’t change, no matter what some bad class libraries may cause you to believe. Even aggregates are values. The set of my favorite foods doesn’t change, i.e. if I prefer different foods in the future, that will be a different set.

Identities are mental tools we use to superimpose continuity on a world which is constantly, functionally, creating new values of itself.

clojure values immutability because it allows people to model real world problems more intuitively while still producing good code, not because it "just needs better data structures or types" or something - https://en.wikipedia.org/wiki/Ship_of_Theseus

we know that we need a very clear "as at" model where all our wasm callbacks and other logic see a consistent view of data (e.g. the value of the source chain cannot change underneath two callbacks that are ostensibly part of the "same workflow") - could immutability crates help us model that better?

[StaticallyTypedAnxiety]

After investigating deadlocks this week and looking at multiple state locations, I think it would be beneficial to have an immutable state with immutable data structures. I think in theory what they say is true, the rust type system is very strong but how strong it is is dependent on how complex the problem becomes. Holochain is a huge codebase with multiple asynchronous operations, having an immutable state would be beneficial because no matter how you model it, you are assured that the operations for the most part have no side effects.

I think it is not only a type issue but it has become a design issue as well.

[thedavidmeister]

@AshantiMutinta i agree, type systems and immutability solve totally different things

i'm a bit lost as to how types could address the things we want immutability to help with in our redux model

the only thing types do is allow us to represent data structures as code structures at the input/output boundaries of logic, for a specific type of compile time checking

you can have all the types you want defining the shape of some mutable data and still have a hot mess on your hands

immutability targets problems of modelling time and identity values (not structures)