Handling callbacks without piles of Rc<RefCell<>> to access widget data, or having vectors simulating graphs, the most used data structure for UI widgets, having to deal with use-after-free indexes.

It sounds like you tried to write rust like it's OOP. You're gonna have a bad time if you do that.

>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?

I have experience with plenty of languages, including doing UI programming in Haskell, just to make your point.

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 don't think Rust has any one answer to a UI problem, since the UI story is basically the wild west right now. Everyone is doing something a little different.

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.

Catherine is relatively known in the Rust community, hence why I didn't mention anything else.

Here is her keynote talk at Rust Conf 2018.

https://youtu.be/aKLntZcp27M

Ah ok had to skim through the slides a bit, I think you meant to use the phrase "generational indexes" which is why googling didn't help me. This project was more helpful for my understanding:

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

Only if you understand by normal Rust code, CLI apps.

If we are talking about graphical applications, that would be a common usage.

> 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.

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.

I'm definitely no GUI framework expert, but I didn't necessarily mean to imply an immediate mode architecture. Personally I've been writing a lot of code that way in retained mode frameworks. There's some duplication of data but it's not a huge deal when a widget's state is just single variant, which covers just about all I need.

>> 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.

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.