Awesome! Does anyone know if there is any similar framework for RUST?
>Handling callbacks without piles of Rc<RefCell<>> to access widget data
That's why you don't let widgets hold program state, they should just propagate deltas and display current state. It's a different way of thinking about how UI can work, but imho it has a lot of benefits aside from just speed and safety.
>having vectors simulating graphs,
You mean adjacency lists? They're a canonical realization of a graph, and a fast one at that.
>having to deal with use-after-free indexes.
What do you mean by this?
That's how delphi does it. Connect widget to a data source and it will update reactively when data source changes. And data source is accessible without touching the widget. When doing a batch update on data, you can also disable widget updates in order to make rendering faster. It also works both ways, so when data is changed from within the widget, the bound data source will be updated accordingly.
If Rust answer to typical UI programming patterns is "you are holding it wrong" then don't expect too much uptake by mainstream UI developers.
See Catherine's talk about their game engine implementation, regarding use-after-free indexes, and techniques to avoid it, by binding timestamps to indexes.
I didn't mean to imply that, just that when I see people complain about the ergonomics of the language and point to using a bunch of Rc<RefCell<T>> stuff usually smells funny, it implies to me that you're either trying to use OO or control flow architectures and patterns, where the type system is able to handle the edge cases that you'd need to think about anyway. There are nicer alternatives, especially in terms of data flow architectures.
And I don't know what you mean by "indexes" in this context or which talk you're referring to, do you have any more details or a link? Google isn't finding me anything.
Here is her keynote talk at Rust Conf 2018.
https://github.com/fitzgen/generational-arena
I'm not sure what your ultimate point was though? You don't have to use anything like that in normal Rust code
If we are talking about graphical applications, that would be a common usage.
My (limited) understanding is that you're describing an immediate mode GUI (as opposed to a retained GUI) and that one isn't strictly better than the other, but rather there are tradeoffs. In either case, I would be a little perturbed if implementing/using a retained mode GUI in Rust was prohibitively difficult even if immediate mode were strictly superior (the language probably shouldn't force such choices). Of course, I'm opining beyond my expertise, so I'm happy to be corrected.