> You’d probably use Arc or create a special custom smart pointer in Rust for use with the Qt paradigm. Simple references probably would not be expressive enoug

> You’d probably use Arc or create a special custom smart pointer in Rust for use with the Qt paradigm. Simple references probably would not be expressive enough for Qt. Shoving Arc everywhere is a great way to leak memory with Rust. No, compiler doesn't prevent that. It is not a safety bug. The problem is Qt has its own ownership model that goes against Rust's ownership model. It is a prime C++98 era library at its heart and it didn't change that much in the core architecture. Moreover Qt relies on heavy use of inheritance-based OOP which is Rust also against. So current Rust GUI libraries using Qt stuff like Slint has to implement a second level of abstraction and state tracking which costs performance. I think the best way ahead is implementing a GUI library (at least the Widgets layer all the way down until rendering engine) in Rust. However I am not really hopeful. Writing GUI toolkits from scratch could be one of the hardest software engineering problems out there. The days when benevolent software companies released open source full-featured GUI frameworks with relatively permissive licenses are mostly behind. Nokia didn't have much to gain from releasing Qt as LGPL but they did it anyway. I don't think today's big tech would do the same unless there is a clear, guaranteed way of monetizing it. Dealing with N dimensional space of multiple OSes with multiple graphics APIs, multimedia engines, high DPI screens and complex text rendering is 90% painful software development. Somebody can do it but I don't think it will be open source, neither cheap.