AudioKitUI VS redux-rs

Ok I'm not Raph but, FWIW, my 3d sculpting app is written using SwiftUI (https://sculptura.app), which is not a view around a database (in fact it was previously UIKit... SwiftUI is so much better). I recently implemented a piano-roll editor in SwiftUI: https://github.com/AudioKit/AudioKitUI/tree/main/Sources/Aud.... I have little doubt a DAW could be implemented in SwiftUI easier than with UIKit or AppKit.

From the first paragraph:

> ... Architectures that work well in other languages generally don’t adapt well to Rust, mostly because they rely on shared mutable state and that is not idiomatic Rust, to put it mildly. ...

The author doesn't mention Redux (the architecture), which is surprising. There are three principles[1]:

1. The global state of your application is stored in an object tree within a single store.

2. The only way to change the state is to emit an action, an object describing what happened.

3. Changes are made with pure functions.

In other words, the components of an application never mutate the state tree directly. Rather, they emit actions which re-generates the state tree without mutation.

This style of state management is compatible with Rust's ownership model. The emphasis on pure functions means that it's not necessary for your application to hold multiple mutable references, which I'm guessing underlies the "generally don't adapt well to Rust" part of the claim.

[1] https://redux.js.org/understanding/thinking-in-redux/three-p...

[2] https://github.com/jaredonline/redux-rs