New programming language needed for KDE?
New programming language needed for KDE?
Open Source Software Development FOSS FLOSS
The C++ committee is actively looking at how something like rust's borrow checker could be added to C++. Likely it won't be a borrow checker, but just enforcement that some code cannot use new/delete and so must use a container (std::unique_ptr, std::vector...) which gets rid of most of the pain. Modern C++ is a much better language than C++98, but I still see a lot of people writing C++98 code.
I have been building a Qt/KDE app in rust using that CXX-QT binding. It's pretty good, but definitely more of a headache to work through the binding than just directly with C++. That being said, I don't feel like I'm about to shoot myself in the foot with rust. Rust just protects and advises the best paths forward. Once KDAB solidifies the binding and perhaps makes it easy for others to create their own extra bindings, (which they don't want to maintain every class in QT so this is necessary) it'll be amazing.
Also, it feels so awesome to build the backbend in rust and the ui in QML.
Qt is a wonderful GUI toolkit, but new language bindings are notoriously difficult, since it depends not only on C++ (which itself is tricky to bind into other languages) but also the Qt meta-object compiler. Even so, some interesting projects have emerged on that front. For example:
This (header-only) library can be used to create an application using Qt, without the need of the moc (MetaObject Compiler). It uses a different set of macro than Qt and templated constexpr code to generate the QMetaObject at compile-time. It is entirely binary compatible with Qt.
DQt:
DQt contains experimental bindings for using a subset of Qt with the D Programming Language. Qt is a library for writing cross-platform graphical user interfaces. Currently bindings exist for the Qt modules core, gui, widgets and webenginewidgets.
without the need of the moc
I got a bit of a mind freeze reading that sentence since my first thought was "why would someone deliberately give up on Qt's reflection system" but only then realized they're still using QMetaObject (the thing that actually enables reflection and signals and slots), just building it with something else.
Yes, exactly. So a standard compiler can be used, making language bindings much cleaner, while the runtime functionality and library compatibility are preserved.
And then there's DQt, which uses DLang's compile-time function execution instead of the meta-object compiler.
@herzenschein
If you are interested in Qt without the MOC I can also recommend @copperspice_cpp that is a fork of Qt4 but relies heavily on#modernCpp
@ono @kde
Yeah, C++ is what's keeping me from switching from Vala/C + Gtk
What about Zig? But I would have to agree that C++ does seem to be holding Qt back from adoption, minus where there are decent bindings.
dart would be a good candidate imo.