Disclaimer: I am not one of KDE's masterminds or spokespersons. I am a mere bystander with few unimportant commits. I follow KDE's ecosystem and other developments in the free software world. In the following, I share some thoughts and my personal opinion.
Talks about new programming languages
After 30 years of C code, the Linux kernel opens itself to a second high-level language: Rust. Since fall of 2022 the kernel mainly gained infrastructure work. Some experiments show promising results like a Rust-based network driver or a scheduler.
Recently, Git developers started to discuss how to allow Rust code in our beloved version control system. Far from having reached a consensus, its media coverage and heated discussions in forums show how interested the public is in this topic.
Other projects try to replace established software by rewritten from scratch Rust ones: uutils coreutils, sudo-rs, librsvg, Rustls. Heck, Rewrite it it Rust (RiiR) has become a meme.
We already have a new programming language!
KDE is close to its 6th Megarelease, with one major change being based on Qt 6. Qt 6 requires C++17 which -- as of today -- is perceived as modern C++ and is a leap compared to C++11. It is possible to write modern software with C++17. Still, additional tools like C++ Core Guidelines or Cppcheck are advised to keep the number of preventable bugs low.
Most of the projects mentioned in the introduction are using C. This inflicts more pain to the developers and thus using Rust is more attractive. For sure, a fair portion of RiiR arguments do not apply to KDE's C++ code base.
Problems with C++ remain
C++ cannot adapt to modern ways like including a borrow checker or a less complicated syntax, as this would break compatibility. As much as C++ improved as a language, its compilers, and its ecosystem, it is not enough to be considered a good choice for new projects. NIST and NSA advice to move away from C++.
Other problems like complicated tooling with variations on different platforms (build systems, compiler, linker, debugger, dependency management), mixed-in C-style code, difficult to parse C++ code, cannot be solved.
I fear that in a not to distant future, C++ might be perceived as an outdated choice to learn and people might less likely consider to join KDE as contributors.
What can be done?
In the past, GNOME adopted Vala as a new language to solve the short-comings of C. Vala seems to be dead. Going with Rust did not lead to a project-wide adoption.
Some people are working on Qt bindings for Rust, e.g., CXX-Qt from KDAB. I am not sure if Qt itself is working on something similar. At least there is no go-to binding.
Beside the hot topic Rust, two big players invest in ways to have good interoperability with existing code bases and a modern language: Cpp2 / cppfront and Carbon.
Cpp2 is a new language from Herb Sutter, who chairs the C++ working group. The idea is to have a transpiler cppfront producing modern C++ code. Cpp2 is not backward compatible to C++ and thus not limited in introducing new ways or removing existing parts. Cpp2 promises to integrate seamlessly in existing C++ code bases as it is compiled into C++ code.
Carbon is a project by Google developers and follows a different approach. It aims to provide a new language that can use all C++ features in interfaces, even templates with all bells and whistles.
Discuss our future
I do not want to whine about C++. I want to start a discussion on how KDE's future might look like. KDE was always driving innovations. We helped CMake to become one of the most important build systems for C++. KDE 4.0 introduced the semantic desktop. KHTML's code base was the nucleus for today's big browsers.
Probably we should have this discussion as a BoF at Akademy 2024 or other places where KDE's masterminds and people with a feeling for future trends come together and form/formulate future directions. In the meantime, I start a discourse thread.
Personally, I would like to see some push for Cpp2. More important, I want to see that we are actively shaping KDE's future.
What about Python? It has official bindings. For most desktop apps it's fast enough. C++ could still be used for performance critical parts.
ReplyDeletePython is has no type system and compiling code helps to reveal bugs. Python is good for smaller projects, plug-ins, or semi-interactively working with large data (big data, ML, numerics).
DeleteFunny thing, this morning I saw a phoronix post where they quote a Linux kernel mailing list message where one of its long time contributors argued about reconsidering the port of the kernel to C++:
ReplyDeletehttps://www.phoronix.com/news/CPP-Linux-Kernel-2024-Discuss
That one is in the top 10 most "discussed" (read: controversial) articles within the last year. There seem to be quite a lot of people that don't agree with it.
DeleteC++ has its advantages over C, no doubt. Switching from C to Rust remains the better choice for the kernel.
DeleteI don't think Rust is a good successor for KDE unless Qt decides to go this way.
It might be the case that we need a new language, but IMO it needs to be something 100% compatible with C++. Even with QML (which you surprisingly ignored), it has been quite the challlenge to adopt. Cpp2/CppFront/whatever are still not up there and we've learned over time that the bindings model doesn't really work. I'd suggest to embrace either how C++ is evolving or engage with helping C++ to progress further. Pushing KDE to change languages can't be the solution as there's nothing around today that we could embrace without wasting big amounts of effort for little gain.
ReplyDeleteCpp2 and Carbon provide perfect interoperability with C++. No bindings involved. Nothing needs to be prepared on the C++ part.
DeleteThe gain is getting rid of 70% of bugs and security issues. This is claimed by Rust, and other modern languages.
QML is for front-end design, less for business logic. This is the reason I omitted it. You are right, this is an additional language and it already partially replaced C++.
People bring up this kind of thing a lot. Many within KDE are personally happy with Rust, and while there are some legitimate criticisms of it (excessive speed of change, packaging challenges) the major problem is that in KDE we are 100% dependent on Qt and Qt technologies, and Qt is a C++ GUI toolkit without any Rust support. I haven't seen any solution to the challenge of writing a GUI in Rust that doesn't involve using a new and immature GUI toolkit that's still in development--let along letting us re-use the existing QML or QtWidgets GUIs of our existing software. So at the current point in time, "rewrite it in Rust" ends up meaning "port it away from Qt" which itself ends up meaning "rewrite it from scratch" which is not feasible for basically anything given KDE's level of resourcing.
ReplyDeleteIt's a little bit more complicated than that. There are existing, decent bindings project that bind QObject from Rust, and allow you to basically write a Rust backend for a Qt Quick application, which looks quite similar to how we combine C++ and QML (with a few more warts). That kind of thing is not that hard, and I'm sure it will not be long until we see the first KDE apps doing this.
Delete(In fact I've done it for personal projects - I wrote a homebrew remote control GUI app for my Android TV. I wrote a Rust lib for the Google remote control protocol and strapped a Kirigami GUI to it - it was an OK dev experience, no major regrets.)
The bigger problem is the C++ APIs in Qt and KF outside basic QObject-exposed-to-QML. Bindings approaches for those are a lot more complex and unwieldy. Basically, anything that can be clicked into Qt Quick and combined/hooked-up there is not that hard, having your Rust backend call into a KF API that is not exposed to Qt Quick is where you run into walls though. That's where something that is more interoperable with C++ such as Cpp2 or Carbon is a lot easier.
No one's talking about porting away from Qt though.
Sticking to Qt is the premise. You are right to emphasis this. I have not heard any plans from Qt how the intend to proceed. They could adapt Cpp2, Carbon, or offer official Rust bindings.
DeleteI agree with the article, but I think that KDE shouldn't even be integrated with Rust. waste time rewriting from 0 no thanks. I think we should help those who have already seen it working on the Rust cosmic desktop for some time... I have been using it for some time and I guarantee that it is a pleasure to use it as well as the performance... I use it every day for work. I'm not a system76 employee, I live in a completely different part of the world. I think system76 should be more open and support everyone not just those who buy PCs from them.
ReplyDeleteI would argue that this "new programming language" is already there.
ReplyDeleteI have personally worked with new and existing PyQt/PyKDE codebases, and found the bindings mature and fairly well documented (perhaps not as well documented as Qt, but that's a high bar). Moreover, there are tons of examples, also of very complex applications, meaning enough to learn from, but also lots of teething problems solved. In my experience, those are the things that make it really hard for a new programming language: running into problems nobody has encountered yet. Not really an issue with Python and PyQt/PyKDE anymore.
Some may say: "BUT PERFORMANCE!!?", though in practice that is often not an issue since performance-critical things are done in the Qt/C++ portions anyway, and if not, there's usually a clear route to rewriting performance-critical bits in C++, should that need arise.
Perhaps instead of following memes, PyQt/PyKDE should be promoted more, they really offer quite a good developer experience while doing away with much of C++'s complexity and arcane syntax.
I too like python for prototyping stuff and simple utilities (no experience with PyQt though). But in my experience the language just doesn't lend it self very well to GUI programming. There is an almost infinite amount of runtime errors that can occur and python does very little to make sure those cases are handled before they reach users.
DeleteI'd like to think part of the motivation for this post was to write better programs (as in: more stable/correct + easier to develop) and I don't think python lends itself very well to doing the first part. (I'm probably biased by the some subpar python tools I've been forced to use, but I'd like to think there is a reason they tend to be so particularly fragile.)
Any programming language that is a “project by Google developers” is a no-go, IMO. Things die there way too fast.
ReplyDeleteThey want to use it for Chrome. This might be big enough to fail. I understand your sentiment.
Delete"C++ ... [has] complicated tooling with variations on different platforms" - this isn't a big, it's a feature: all the other languages mentioned do not have that feature because they aren't standards - they are an implementation. There is one Rust compiler because Rust is not the language, it's the software project (granted, they also call the language "Rust", which theoretically can be implemented by another compiler - but it never did and never will be, so why be less confusing if you don't have to?).
ReplyDeleteIf KDE will standardize on a single C++ implementation, maybe one that supports modules, and allows for modifying the compiler frontend (e.g. clang), then most of the issues with keeping the current setup, that were discussed here, immediately go away.
But creating software in a standard language has benefits that weren't mentioned here and are important - skill transferability and lower barriers of entry for experienced programmers. This is important - I don't know how many developers skipped on joining the GNOME community because of the GObject confusing mess and instead started working on KDE with it's much more friendly and standard object model, but I have heard personal accounts.
I think you missed my point. Having great tooling helps finding bugs and keeps the quality of produced code up. C++ never had this compared to Java (at least 20 years back), Go or Rust.
DeleteGreat tooling is important. clang-tidy and clang-format are already in use by KDE, but the LLVM project has more tooling available, such as the Clang Static Analyzer which can solve a lot (though not all) of the issues that a "memory-safe language" tries to solve, in addition to many other issues.
DeleteI write extensively in Java (in addition to C++), a bit in Go and tried my hand at a bit of Rust (so I can claim that I know what I'm talking about), and most of the "tooling" I enjoy in these simpler languages are based on the fact that these are much simpler languages that are easier to manipulate programmatically - something that C++ does not enjoy and I don't see anything that claims source compatibility with C++ (and less than 20 years of history) to be able to achieve.