I’d love to see support for Go or Rust. Go seems particularly well suited and would be extremely productive for this kind of programming.
I’d love to see support for Go or Rust. Go seems particularly well suited and would be extremely productive for this kind of programming.
Qt objects have to be heap allocated anyway so you would not be adding much overhead. If you designed a specialized container it could probably be zero overhead.
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.
Compared to the other languages you listed, it demonstrably is. They've been around for over 10 years and aren't used much for the purpose. Maybe Rust and Go just aren't good (let alone great) for building GUI apps.
I'm a bit afraid of the FFI costs but I will look into the nitty gritty later.
There is always possibilities for the electron/tauri/wails route if all else fails.
I’m writing some data exploration/visualization tooling with it.
I really appreciate the permissive licensing vs Qt.
I totally understand that nobody would want to learn C++, of all languages, in order to make their pet music collection manager, or whatever other app. I'd wager for 95% of apps, the fine control over memory and resources is just a premature optimization, and only brings friction by requiring to learn an arguably difficult to master language.
Go would be a great choice for general application development. Of course you might want to use C++ or Rust for a complex video editing package or something demanding like that... but to make the To-Do or Calculator app du jour, having to learn those languages is overkill. I guess that's also why there are so many Electron-based applications.
In general, having a garbage collector is a huge productivity boon, while not having to distribute a runtime interpreter (that's why I didn't mention Python) is also great.