5 ms·
I suspect the mismatch is actually due to the borrow checker's inability to do various common abstractions such as delegates and observers. These patterns are
by verdagon 4y ago
I suspect the mismatch is actually due to the borrow checker's inability to do various common abstractions such as delegates and observers.
These patterns are quite useful, especially in stateful situations such as GUI. They help decouple observer from observable, and can give an architecture more flexibility in a lot of ways. Alas, the borrow checker isn't very amenable to that sort of style.
- iovrthoughtthis 4y agoyup. we need to find a way to manage multiple owned borrows safely
- tene 4y agoWe already have a way, reference counting and locking, the same way it's handled in most dynlangs.
- jollybean 4y agoThe borrow checkers inability to do those abstractions is evidence of the greater ontological mismatch ... which is my point. UI's are 'inherently' trees, data that needs to be mutated, at least some degree of self and circular referencing. All of that a bit outside of Rust scope. More pragmatically, UI code tends to be 'wide and flat' - i.e. a ton of 'little things' and screens, mostly independent from one another, with visual elements. You really want to be able to code fast, compile fast, 'try things' for validation. Performance is usually not a primary concern. That's contrary to Rust ethos where they trade all of that away for performance. So, it's a bit upside down in my view. Rust UIs I can see for automotive, critical systems etc. - but even then - I suggest the UI should be disassociated from the 'critical' part.