I tried event-driven programming with Rust 4 years ago and came to the same conclusion. It just isn't a good fit for the language. Rust works best when there i

I tried event-driven programming with Rust 4 years ago and came to the same conclusion. It just isn't a good fit for the language. Rust works best when there is a stack and clear ownership semantics. Any kind of callbacks cause a certain amount of pain due to the need for unergonomic wrapper types. Since then it got better libraries which reduce lots of the verbosity (e.g. gtk-rs), which is great. But the language itself probably won't change too much to better accommodate that use-case, since what things things painful here are the core features that prevent issues elsewhere. I think we have to accept the fact that for different kinds of problems different programing languages are preferable instead of trying to find a single solution for all problems. For UIs I think a naturally garbage-collected or refcounted language with reasonable support for dynamic dispatch is a lot easier to work with. In addition to that a restriction towards a single thread or even an inbuilt event loop can avoid bugs, improve interoperability between libraries, and reduce the amount of boilerplate and application-level design decisions even further. If we take those properties we get the most common languages for GUI apps: Javascript/Dart which have single-threaded runtimes, and C#/Java/Kotlin/Swift as general-purpose languages which are more powerful but require an eventloop on application/library/framework level. Those properties actually also expand to other very stateful and very concurrent applications. E.g. stateful network servers (something like Redis or a websocket server) have similar implementation challenges, and therefore are currently not very straightforward to write in Rust either (compared to e.g. in node.js).