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.
My biggest hurdle when coming to C++ and C world was header files.
Having to remember to modify something in two places is stupid.
C++ modules alone could help reduce the cognitive load.
As for completely new language, I think anything that can interop with C++ code without too much effort can work. I think Zig language can use C++ but not sure… Despite that, it’s not mature at all yet.
The best case, imo, would be allowing any language that can work with the existing C++ code.
Going away from C++ may encourage new contributions but may turn away current contributors just as well.
KDE is a mature project and has to be created using mature tools. The only new language coming close to C++ in this aspect is Rust. It is also one of the few that has actually better language design and doesn’t just benefit from being new.
Rust is a great language, but it has a learning curve steeper than even that of C++, which can also prevent contributions.
Introducing Rust will also need infrastructure for mixing languages, initially making build systems even more complicated, and it will definitely introduce bugs of its own.
With how much improvements new C++ standards see, how good modern static analyzers are, and how much ugly things Qt and KDE frameworks can hide, this is a lot of trouble for not so much in return.
It would be great to adopt Rust in core parts of KDE like KIO, KAuth, maybe KWin. It has great potential there, but doing it will be difficult. While for most apps, it doesn’t make much sense.
I’m a experienced software dev of business applications with web applications. I just discovered the linux ecosystem (especially kde) and I’m very interested in contributing. But I have no clue about C++ AND Qt. Learning both is overwelming to me, especially since I can’t reuse that knowledge at work. Learning C++ is hard to me and I would rather learn something trending new than a dinosaur (sorry for the analogy)
I’m a business owner and I also have to deal with these kind of questions and choices. I took the approach, that I choose languages/technologies not by its features, but by its popularity (including trends). This ensures me that I have a decent pool of knowledge around. Since KDE lives from unpaid contributions, people need not only to invest time in code, but also in learning that tech.
This hurdle must be as low as possible to get new contributers. But on the other hand, you also need kind of a consistency that code stays maintanable (this is where C++ shines) .
So to me, a new language must be trending and still be important in 10+ years. The only choice I see here is rust. I don’t think that any other (like Cpp2) will remain for that kind of period.
So if another is chosen, it would be wise to use rust.
another question: Is it really either or? I think coexistence of C++ and Rust should be possible. This would get new contributers and keep the old ones on board
I think rather than to ask which language we could move toward, the question should be which parts of KDE we don’t need Qt-on-C++ for.
Can we move background services and privileged KAuth helpers to Rust, communicating via D-Bus? Can we make a QML/Kirigami app with purely Python as the back-end language and define item models in it for use by QML front-ends? Where do we point people for the relevant documentation? Can we find surface areas where plugins written in any language can be plugged in, as opposed to requiring a strictly Qt/C++ binary interface? How do I go about creating a Plasma data engine in Go? How do we provide common functionality to build systems popular in other language ecosystems?
There’s a lot of stuff that could and probably needs to be done before we even get to the core parts that one often associates with KDE and C++. An openness toward other languages may need to entail throwing Qt out of some of our basic interfaces and replacing it with more binding-friendly infrastructure.
I personally plan to explore the newly introduced Swift/C++ interoperability features with KDE in the future. I will report back, probably in the form of a blog post.
I generally hate bindings.
You get bad documentation, APIs that don’t fit the language idioms, and code can’t be copy pasted between projects or upstreamed into libraries.
If we are going to look into more languages we should look into the existing Python infra we have. It has first party support from Qt, with documentation and examples written natively. Python is still one of the most popular languages in a recent github survey especially with the AI side of things that’s booming these last few years.
Before we add any new language support we need to answer the question of why is this not seeing wider adoption at an application level? and what is going to be different about anything else?
Python has its use cases. Data analysis is one of them. I do not see advantages in a type-less language for a desktop and its applications.
My hope with a new language like Cpp2 or Carbon would be increased productivity, reduced build time, less error-prone (bugs, security issues), increase of potential contributors.
You can’t expect new contributions by using technology that has zero outside adoption. Carbon and Cpp2 are such technologies. Rust and Python are not.
Python is far from typeless, especially with tools like mypy. It would make a lot of sense for developing apps. KDE could also give Python devs a better experience with developing user interfaces and get some extra development time for frameworks on this.
Python has great potential in apps, Rust in the core. These could work out well if somehow adopted gradually.
One thing that could help with gradually adopting new tech (any kind of it) is decreasing the reliance on libraries to share code, and increasing reliance on services where possible.
One thing that could help with gradually adopting new tech (any kind of it) is decreasing the reliance on libraries to share code, and increasing reliance on services where possible.
KDE offers a bunch of services. Do you have specific cases in mind?
It won’t. While modules make it technically possible to have it in one place, you are still advised to split implementation in separate file otherwise changing implementation will trigger recompilation of BMI and therefore all its dependents (it’s similar to putting implementation in header but without ODR issues). I suppose it could be solved at build system level (result of BMI recompilation in this case should be the same and build system could track this) but I don’t know whether any of build systems supporting modules currently do this.
My personal opinion - as long as KDE uses Qt it is pointless to use anything other than C++. Qt is C++ framework and makes uses C++ to its fullest (and has huge API surface). Binding to other languages will always have issues and extremely high maintenance cost. It’s a bit better with highly dynamic languages like Python but still not ideal. And you are still running into a fundamental issue - you are not using Qt as it’s meant to used, and this will always have a cost to it.
If another programming language is to be used, then with something else than Qt - and of course that something else needs to be native to that language’s ecosystem.
Short of allowing another GUI framework (or Python GUI apps that use official bindings) I feel like the only avenue that might work is command-line tools and background services that don’t need GUI. Not sure about plugins and other stuff. That will still require bindings and infrastructure work, which will probably will be done by a single person who is passionate about language in question. And it won’t be one-time endeavor - you will need to dive into that every time you need to refactor stuff or tackle technical debt around public interfaces, like the work that was done in Plasma 6 transition. What if that person leaves the project for whatever reason? Someone will need to step up and learn everything from scratch.
replacing the entirety of kde because “c++ is to hard for some people and there are more trender programming languages out there” has made me lose all faith in John Linux and Mary Gnus kernel. im now going to live like Tom Hanks in cast away and abandon technology altogether just from reading this post.
its concerning to see how many people want kde rewritten in python.
first off python is a interpreted language and as such is slower than c/c++ or rust. And when I mean slow I mean noticeably slower. https://www.youtube.com/watch?v=VioxsWYzoJk (comparison of what im talking about. Python is a lot slower than c++)
Also lets also consider the fact that when making guis, c++ is generally the goto thing(yes i know c# is popular but that’s mainly because of .Net and visual studio on windows). As history has taught us Replacing a standard is generally really hard and time consuming it takes years to get people to switch because people are hesitant to change. because of this people build on top of the standard to improve it.
Or some language officially supported by Qt. They might consider support Rust with bindings or use Cpp2 or Carbon internally, too. I have not heard any announcement or rumors.