back

by raphlinus·4y ago·view on hn ↗
So I read the 7 month old thread, and I found this comment particularly interesting: https://news.ycombinator.com/item?id=28332803

Basically, it answers the question, "why do Rust GUI frameworks use enums rather than closures for messages in the Elm update pattern?" It is very insightful, but doesn't tell the whole story. In particular, as a major counterexample, Druid does use closures for stuff like buttons, and they update state exactly as expected. That said, the Druid approach does have major drawbacks, chief among them that the app state needs a `Data` bound, which (oversimplifying slightly) means that it only works well with immutable data structures.

As it turns out, I've been thinking about how to solve this problem - closures that have convenient access to mutable app state without strange bounds on that state, or strange control flow when doing things like adding and deleting widgets, and think I've finally cracked it. I will be doing a writeup when I have time, but for the eager and curious, there is a code sketch at https://github.com/linebender/druid/blob/lasagna/lasagna/src... .

2 comments
druid is really cool. it's great to see so many ui libraries (druid, iced, rui and egui) come out for rust.
Interesting comment you are referencing to. I came into these problems when trying to implement the observer pattern with a similar interface than tc-39 proposal and banged my head against the same "limitations". The important take away I think:

> our intuitions about using closures for this stuff in functional or garbage collected languages don't apply here--patterns that make a lot of sense in them don't work at all in Rust