There are quite some challenges. Qt, like most C++ programs can exhibit undefined behavior. In Rust, no code is allowed to have undefined behavior [0]. For safe

There are quite some challenges. Qt, like most C++ programs can exhibit undefined behavior. In Rust, no code is allowed to have undefined behavior [0]. For safe functions, the compiler checks this. For unsafe functions, the function documentation should state how to call the function to avoid undefined behavior. Qt is enormous. There are projects that generate bindings automatically. But to know what is safe, you'd have to read the API docs and write the binding by hand. Some parts of Qt might never be safe. For example, loading QML with QQmlApplicationEngine::loadData is not safe because it runs possibly unsafe QML code. So a binding to QQmlApplicationEngine::loadData should be marked unsafe and its documentations should state: 'only load safe QML'. Most current FFI examples in Rust go via C bindings. There's not a lot of work on wrapping C++ libraries yet (that I'm aware of). C++ is vastly more complex than C. So ensuring safety is harder. In most Qt projects, there will be places in the code where you have to derive from a Qt class. So the binding should have a way to do that. The Qt ownership models is hierarchical. If an object has a parent, it will be freed when the parent is freed. A Rust binding should translate that behavior in a safe API. Signals and slots in Qt are tricky to wrap in a safe API too. In short, wrapping Qt in a Rust API is a humongous task. Rust Qt Binding Generator takes a pragmatic approach and lets you combine Qt and Rust in one project. It does so by generating a binding around your data model instead of around the entire Qt API. [0] https://doc.rust-lang.org/reference/behavior-considered-undefined.html https://doc.rust-lang.org/reference/behavior-considered-unde...