Feed aggregator

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.

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.

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.

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.

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.