4 ms·

Qt itself is nice but C++ is just not the greatest language for building GUI apps. I’d love to see support for Go or Rust. Go seems particularly well suited an

by api 3y ago

Qt itself is nice but C++ is just not the greatest language for building GUI apps. 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.

jcelerier 3y ago
For Rust it's not that easy: Qt's basic model is a tree of widgets, where the parents know (and own) their children aaand the children also know their parents, which from what I understood creates ownership cycles (all handled automatically by Qt obviously but the Rust borrow checker cannot really be made aware of it). Basically a lot of ownership transfer happens behind the scene in Qt to make sure that things "just work" and that you don't have to call delete manually for each widget.
- api 3y ago
  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. 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.
  - jcelerier 3y ago
    Well that's the thing, Qt already has its smart pointer types which work with the QObject system - e.g. QPointer. You certainly wouldn't want to have a double layer of indirection, just like std::shared_ptr<QStuff> is an antipattern
  - okanat 3y ago
    > 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.
aatd86 3y ago
I'm currently building something in Go that should eventually work with Qt as one of the underlying drivers if that's possible. 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.
saidinesh5 3y ago
Rust has quite decent support for QML though. One of the really famous video footage stabilizer apps uses Rust with QML: https://docs.gyroflow.xyz/app/technical-details/used-technologies https://docs.gyroflow.xyz/app/technical-details/used-technol..., and that is a non trivial UI: https://gyroflow.xyz/ https://gyroflow.xyz/
j1elo 3y ago
Having been involved as a C++/Qt developer for years, I also agree that C++ is a big hindrance for adoption of 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.
- zerr 3y ago
  The main downside of becoming a C++ dev is that all of other languages seem so inferior.
jenadine 3y ago
If you want to use Rust, you can use the Slint toolkit. It is really similar to QML.
- bkinman 3y ago
  I’m really happy that slint exists. I hope it gains traction. I’m writing some data exploration/visualization tooling with it. I really appreciate the permissive licensing vs Qt.
- xrd 3y ago
  Great recommendation. Thanks!
justin66 3y ago
> C++ is just not the greatest language for building GUI apps. 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.

by api 3y ago

jcelerier 3y ago

For Rust it's not that easy: Qt's basic model is a tree of widgets, where the parents know (and own) their children aaand the children also know their parents, which from what I understood creates ownership cycles (all handled automatically by Qt obviously but the Rust borrow checker cannot really be made aware of it). Basically a lot of ownership transfer happens behind the scene in Qt to make sure that things "just work" and that you don't have to call delete manually for each widget.

api 3y ago
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. 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.
- jcelerier 3y ago
  Well that's the thing, Qt already has its smart pointer types which work with the QObject system - e.g. QPointer. You certainly wouldn't want to have a double layer of indirection, just like std::shared_ptr<QStuff> is an antipattern
- okanat 3y ago
  > 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.

aatd86 3y ago

I'm currently building something in Go that should eventually work with Qt as one of the underlying drivers if that's possible. 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.

saidinesh5 3y ago

Rust has quite decent support for QML though. One of the really famous video footage stabilizer apps uses Rust with QML: https://docs.gyroflow.xyz/app/technical-details/used-technologies https://docs.gyroflow.xyz/app/technical-details/used-technol..., and that is a non trivial UI: https://gyroflow.xyz/ https://gyroflow.xyz/

j1elo 3y ago

Having been involved as a C++/Qt developer for years, I also agree that C++ is a big hindrance for adoption of 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.

zerr 3y ago
The main downside of becoming a C++ dev is that all of other languages seem so inferior.

jenadine 3y ago

If you want to use Rust, you can use the Slint toolkit. It is really similar to QML.

bkinman 3y ago
I’m really happy that slint exists. I hope it gains traction. I’m writing some data exploration/visualization tooling with it. I really appreciate the permissive licensing vs Qt.
xrd 3y ago
Great recommendation. Thanks!

justin66 3y ago

> C++ is just not the greatest language for building GUI apps. 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.