Once Qt is properly accessible in Rust, I think your claim will be a lot more realistic. This goes for other important C/C++ libraries (e.g. libavcodec, vips/ImageMagick, VTK) without a solid (maintained, documented, etc...) Rust interface.
The fact that lists like yours so often end up being "Look at all these C libraries" ie not actually about C++ at all is revealing. It's an endorsement of Bjarne's position that he needed that C compatibility, decades later C++ alternatives remain unpopular but it also tells you that you're never going to raise the bar this way. C++ is not a route out.
AFAIK there is no equivalent of rustls-openssl-compat for C++. The knowledge that this library (OpenSSL) is trash never spurred any C++ programmers to do better and provide the same ABI but with a C++ implementation.
I'm not in love with them or the abomination known as C++, if that's what you're implying.
How so? This definitely needs at least a citation of somebody who can explain in detail why this code is "impossible to rewrite". Who wrote the one we have now, Martians?
What would you say is missing in Slint?
> probably not much harder than wrapping Qt, to be honest
There are already Qt bindings for rust (cxx-qt, qmetaobject-rs). What's missing from these?