Iced: Why messages over callbacks?

[jgarvin]

I never used Elm, so I'm just going by my experience using iced, but it feels like iced is asking me to go through extra hoops to write callbacks. I have been working through the tour example, trying to modify it to resemble the GUI I want. Say I want some code to run when the user presses a button. In other GUI frameworks you would pass a callback to the button when constructing the button. In the tour example I have to go through extra song and dance to get the same effect -- I need to define a message type, then I need to add a constructor corresponding to that particular button, then I need to add a new pattern match inside my update method, then I get to write the code I actually originally wanted to write. I assume there are some advantages to doing it this way but as a newbie it's not clear to me. Why is this preferred?

[twitchyliquid64]

Iced is based off Elm - most evident in it structuring things into messages, views, and state. It sounds like you are used to an event driven API, or a retained mode API like in GTK. This is one way of doing things, but not the only way.

I can't speak for Iced' author, but personally ive found the more verbose state + view + message approach to scale better than using a callbacks API that hides the message passing. Ive found composing messages and state objects to be more understandable and readable as the project gets larger, compared to yeeting gobject callbacks everywhere as is the case with GTK. But thats just my opinion.

Another reason the callbacks approach might not be ideal is Rust lifetimes. A lot of GUI frameworks implement a retained-mode API with garbage collection of unused objects, which lets them do whatever they like with callbacks and objects without having to worry about lifetimes. Iced has no such overhead, but has to be clever about the types and API as a result. How would you prove to Rust that all references you use in your callback will be alive for as long as the callback is callable?