Language Bindings: The Future of KDE?

So um hello hello hello. Is that working? >> Hello again. >> I know, right? Um, we're going to give everyone a couple of minutes because this is the only talk without a five minute gap between from what's happening next door. So, we'll just give everyone half a chance because there's nothing coming afterwards. >> Fine. I'm calling it there. Okay. So, final talk of the day um by Nico and it'll be on language bindings, the future of KDE. Question mark. All right. Before I get started, I want to address the potential elephant in the room. If you seen Christian's talk earlier today, none of what I'm going to say is is necessarily going to be mutually exclusive with that. So, let's just see where it takes us. So to start off, I have a question for you. How many lines of code do you think KDE has? Who raise your hands? Who thinks we have more than a 100,000? More than 500,000, more than a million, two million, five million, 10 million, 20 million. a billion. So the the answer is it's round in about 15 million lines of code which I would classify as a lot. It shouldn't come as a surprise to you that most of that is C++ uh with QML being the runner up in that regard and a bunch of stragglers. So the question is why C++ and part of that answer is because our elders decided that for us at a time where I wasn't even born and now I have to suffer their consequences. But there's also many good reasons for using C++. First and foremost, we use cute. Cute uses C++ for its implementation and its primary API and for good reason. It is a very powerful and flexible language that allows you to do a lot of things in a performant way. It not only allows you some low-level access to your hardware, it also allows us to build highlevel abstractions on top of that. And it's available on all the platforms we care about. It has loads of libraries and tools available in the wild. And also important for us, it's almost transparently compatible to C. So you can we can very easily incorporate C libraries in our development, which isn't necessarily the case for other programming languages. But there's also reasons against using C++. C++ for all its power is a rather complex programming language with lots of features and corner cases to learn about, but it doesn't necessarily always come with all the batteries included that you might want. But it does come with a whole lot of foot guns and that makes it very easy to make mistakes when programming with C++ in particular around things like memory management, lifetimes, out ofbound accesses, user after freeze and so on. And not only is it annoying when your program is crashing, it can also cause security vulnerabilities. And we don't want to be hacked, right? Right. And as rich as the library and tooling ecosystem is, it's also sort of fragmented. We have different compilers for different platforms. Some of them having their own quirks. Uh libraries are sometimes following their own paradigms. Like cute for example is sort of its own little island in in the C++ ecosystem. and sometimes it doesn't necessarily mix well with other parts of that ecosystem. And all of these reasons and a bunch more make C++ not a particularly attractive language for many people. And I guess most of us are here because we can at least tolerate C++ and write code using it. But as a community, we constantly need to attract new people in our communities, and it's getting increasingly harder to do that with C++ as our primary programming language. So, what do we do about that? You might already glean at what I'm getting at. We need a programming language that has all of the power of C++ allows us to write efficient code, give us high level abstractions, have a rich and good tooling ecosystem, and avoid some of the mistakes that C++ has. And drum roll, the one of the solutions being proposed would be Rust. This isn't the first time that somebody's talking about Rust in KDE at Academy. So I'm going to spare you most of the details of the Rust pitch because you probably have heard it before. But just as a quick summary, the core feature that is advertised for Rust is memory safety being built into the language. There's a very powerful system inside of Rust that helps you intrinsically avoid a lot of the programming errors that we make in C++ and generally it has a lot improved language economics and semantics over C++. Sometimes it's compared with modern C++ but if you applied all of the principles consistently and with better defaults and there is something to that argument. It has a rich and also fairly consistent unlike C++ in itself dependency ecosystem. There's loads of crates for all kinds of purposes that we might want to do. And maybe the most convincing reason for using Rust in in in KDE is we already do it. Now, of course, we're going to not we're not going to rewrite all 15 million lines of KDE code in Rust. Not by tomorrow, not anytime soon. Probably not ever. So if we were to adopt more Rust, we need to have some interoperability between C++ and Rust. Rust itself comes with uh interoperability with C out of the box both ways, but that's not really a a great and ergonomic thing to use if you're used to C++ because C is lacking a lot of the highlevel concepts that both Rust and C++ have. For example, both Rust and C++ have the concept of an optional value or a vector of items or a unique pointer, but C doesn't have that. So, if you want to do the interrop via C AI, you need to take your highle concepts, break them down into pieces that C understands, transfer them to the other side, and build that back up again. And if you do that a couple of times, it gets really boring and tedious and you don't want to do that. Fortunately for us, there's solutions for this. One of them is the crate called CXX, which aims at exactly this sort of high level interoperability between Rust and C++ and do it in a way that is as safe as possible. uh internally it still uses that CFFI mechanism as its implementation but it does all of the boring work for you and that also works in both directions. So you can call Rust code from C++ and you can call C++ code from Rust which is exactly what we need. Then looking at cute, cute builds its own sort of types and concepts and abstractions on top of C++. So we need to also represent that somehow in Rust. And for that there exists the project called CXXQ which basically extends CXX with knowledge about the types and concepts that cute provides. What it does not do, however, is make the entirety of the cute API available to Rust. There's not that many reasons why it couldn't do that if that's what we wanted, but it doesn't right now. Whether it should do that is an interesting question to discuss. And speaking on a build system level in KDE we typically use CMake for our build system and for good reasons. In Rust the primary build system used is cargo which is not CMake but it's laser focused on supporting and building Rust code. So if you want to mix those two worlds, there exists a project called corrosion which basically adds helper functions for our CMake code to be able to build and import Rust projects. So we can have Rust build integrated in our CMake build system. I've mentioned that we're already using Rust in in KDE. So you might ask where do we do that? One example is that in actually two different projects in anglefish which is our mobile web browser and in some places in K pim we do at blocking and for that we use a create called I think at blocking or or at block which does things like maintain a list of things to be blocked and by just by being able to use that external library that external crate We can simplify our code a lot but of course that means we need now have a rust dependency in these projects. Another place where we use rust already in KDE PIM is for HTML parsing because surprise parsing HTML safely and securely and fast is actually very complicated. So somebody has done that already for us and Rust is a language that lends itself very well for that kind of task. So it seems natural that somebody did it in Rust and we can reuse their work. And Ian talked about union earlier today. Union internally uses a rust library for parsing of CSS which is then wrapped with CX and corrosion and so on. So we can import and use it in union which is based on C++ primarily. Now what all of these things uh where I've mentioned we're using Rust and K have in common is why we do use Rust code there the Rust code doesn't really tend to interact with KDE APIs a lot but the more we would use Rust the more we would find places where that is needed. So what we need in those cases is actually rust bindings for KDE libraries like KDE frameworks and for that uh Daran during Google sum of code has started to develop CXX KDE frameworks which is a project that builds on top of CXX and CXX cute with all of the same principles applied and add support for using some selected APIs from KD KD frameworks in Rust. In particular, it covers parts of K core add-ons, KITNN, K crash, K config widgets, K icon themes, and KCM utils. Now, you might ask, Nico, this all sounds great, but what can I actually do with that? Now, well, first and foremost, it covers some basic needs for like your basic application setup. like you want to set up your K about data so the application knows what it is uh can show the the proper name of the application give you a list of developers you can use it to set up translations for the project you can use it to opt into our crash handling system that kind of low-level application building blocks another thing we started on is being able to use Rust as the backend language for system settings modules. So currently system settings modules are a mix of QML for the UI and C++ for the back end. But with the support from CX execute that could eventually be just QML plus plus Rust for a system settings module. And very similarly I have an open merge request to add the necessarily glue to write kio workers in rust which is also a very interesting thing because a it allows reuse of interesting crates and b low-level file operation is also something where rust can give us a lot of beneficial things. All of that said, no tool is ever perfect. And Rust being a tool is very much not perfect. Don't get me wrong, I like Rust a lot, and I think it's a great choice for many things in KDE, but it has its downsides. One of them being if you're not used to it, it can be sort of hard to approach because the the mechanism that makes Rust great and gives you all that memory safety, the borrow checker also enforces or makes the application structure a bit more rigid and unflexible and that takes a while to get used to. We also don't have perfect cute support in Rust. While the basic mechanism of CXs cute is certainly impressive, it's far from complete. So as of right now, cute is definitely not yet the solution for doing UI and Rust. And I'm not sure it will ever be. And all of that makes it not necessarily an ideal candidate for this sort of application topmost layer glue code that is just uh assign a push button to a layout, put that layout in somewhere else and then show it as a window. And for for that kind of purpose, there might be better languages out there. So what we really want for at least some of the use cases we have in KDE, we want a language that is not necessarily simple but approachable to learn. Ideally something that is widespread and people already know. It needs to be crossplatform at least for all the platforms we care. It should have a rich dependency ecosystem so we don't have to reinvent all the wheels and ideally it would have good interoperability with cute already. And I think there's one language that checks all of these boxes and that's Python. Cute has supported Python first party for a while now on the DQ for Python or Pyite project. It's been mature and tested for many years already and there's loads of developers out there that do already use cute with Python all the time for their needs and very important for our own purposes. It does not only allow you to use the existing cute bindings. It also allows you to write your own bindings for your own C++ libraries with a tool called Shiboken. So another thing that happened during Google Summer of Code last year is that Manuel was working on sort of reviving an existing old idea of having uh Python bindings for KD frameworks. This time based on cute for Python/ Pyite instead of a different technology. And thanks to that work, we now have Python bindings for the majority of a bunch of frameworks including Kore add-ons, GUI add-ons, widgets add-ons, notifications, KXML GUI, K status notifier item, KUnit conversion, and K job widgets. Very similarly, that allows you to create that sort of low-level application glue that you sort of need to make your plain cute app into a more KDE flavored app and make some use of some of the functionality we have in KDE frameworks. And overall, I think the story for let's make a a cute or KDE app in Python is a lot more mature than it is for Rust. So where does that leave us? I am arguing here that both Python and Rust have their strengths, have their weaknesses. They complement each other very well, I think. And I think both are a good fit for KDE, but for different purposes. Neither of them is very likely going to replace C++ fully anytime soon simply because we have way too much existing C++ code that we're not going to rewrite. For Python specifically, I think it makes the most sense at the sort of topmost uh application layer right below QML or in combination with cute widgets. Python in general is very good and sort of its primary purpose is tying together modules that are written in other languages and when it's used in that way the raw performance of the Python interpreter is not really a topmost concern but if you're doing some sort of intense data crunching Python is probably not going to be the right choice and it might make more sense to do it in for example C++ or Rust. While it's now possible to use a bunch of KD frameworks API with Python, one part of the overall story that still needs attention is the distribution of it because particularly with Python that's a very challenging topic in itself and in particular something we are missing right now is the ability to just do pip install Koreons for example. because we haven't packaged things up to to work that way. But that's something that Python developers expect to work. And as Christian mentioned earlier today, we have to meet developers where they are and give them the the ability to work the way they are used to. And if we just say, well, if you want the Python bindings, go install them from your Linux distribution. That's going to be important for some, but it's not going to satisfy all of them. So that's something we still need to look into. As for Rust, uh there's this meme going around with rewriting everything in Rust. I do not think that this makes sense for KDE because if we tried, we would probably not finish before I retire and I'm not that old yet. I think where Rust really shines or can shine in KDE is towards the lower parts of our stack like file parsing, file handling, input handling. Where it doesn't shine is application layout, shoving push buttons around. I think it makes a lot of sense where we can leverage the existing crates ecosystem. If if we have a task at hand and there's a crate for that and no equivalent C++ library, that's a very solid use case for using Rust in particular. It makes sense where the thing we're doing is security sensitive like parsing images for example. But even for those cases, it's not necessarily clearcut if rewriting existing code in Rust is a good idea. But I would argue that whenever we uh rewrite or create whole new modules or subsystems or just larger parts of the functionality, then we should really consider whether Rust is a good fit for that and whether these sort of the interfaces between the new code and the old code lend themselves to uh to that kind of interoperability or if that would be too complex and I think it's really often a case by case decision on that. Now uh even with Python we don't have bindings for all of the libraries we have and I don't think it's really even feasible to do that because it's just a lot of work and sometimes I don't think it's even necessary. It doesn't really make sense when we want to for example parse uh iical calendar events to create a python or rust wrapper around kcal core which is a C++ wrapper around lipal which is a C library that does the actual work. So I'm very sure that there are great solutions for write reading and writing Ical files uh natively in both Rust and Python. But I'm also skeptical about just blindly adopting them because there is absolutely no guarantee that they're going to be better than K calendar core what we have right now. So I'm very hesitant about just blindly replacing everything that we have with somebody else's code. Creating bindings or wrapping our code in another language makes a lot of sense when the functionality we are talking about is exclusive to KDE like Kio workers for example or really a lot of other things in KDF frameworks. It also makes sense if the type we're talking about is used in the interface of another type. For example, Kconig is not only used directly to read and write config. It's also used in the API of other types to exchange config data. And if we want to wrap those types in another language, then we probably also need to wrap API from Kconig just to have the APIs representable in the other language. And sometimes maybe we have some functionality that isn't necessarily inherent to KDE but we have the only implementation out there and there it might just make sense to to implement or to implement that by wrapping a KDE library in another language. Now there are some challenges naturally with everything I've talked about. One thing I very much like about KDE as it is right now there is a a good amount of technical consistency between various KDE projects in their coding style and practices, how they do dependency management and various things like that. And if we now mix a couple of additional programming languages in there, that jeopardizes this technical consistency and it would make it potentially less likely for people to being able to quickly move on between different KD projects and effectively contribute to them. Creating good bindings for Python and Rust is also not an easy task as Christian also mentioned today and it takes a lot of work and not all API concepts are necessarily representable in another programming language and generally it's it's not a trivial process to do. It's not rocket science, but it's also far from approachable for an average newcomer. And one of the things that we risk here is that if we expect people to come into our community right now, we expect them to be able to at least somewhat work with C++. If we throw in Rust into the mix, we're not only expecting people to be comfortable with working with C++ and Rust, but also the interoperability of those. And what we're really risking here is a sort of social community fragmentation where people will say, "Oh, I wanted to contribute to this project, but it's written in Rust. I don't know that. I don't like that. I don't want to learn that. I'm just not going to bother." And that would would really be a sad outcome and something we should very much try to avoid. Also, whatever we do with our approach to using uh language of languages in KDE, we need to make sure we have really solid documentation about how all of that works. Not only from an API documentation perspective, but also from a perspective of okay, how do I how do I do bindings? How do I package all of those things so I can distribute them? And finally, it sort of raises interesting questions about our identity as a community. Do we identify ourselves as a community that creates C++ software? Personally, I would advocate that there is more that ties us together as a community than our shared choice of programming language. But what exactly that is is something to potentially discuss over a beverage over the next couple of days. And with that, I am at the end of my presentation [Applause] >> question. Thank you. This was very interesting. Um, I am interested in knowing if you have any specific thoughts about how we can address these challenges. Uh, because when I see those bullet points, I feel like I see a little bit of that having already happened with the split between cute widgets and cutequick, for example. And I'm wonder maybe address that sort of thing or prevent it from worsening over time. I think the the best thing we can probably do is just education. So when it comes to people not knowing a certain programming language then showing them here this is how you can learn about it. This is how you can learn about the interpability having solid documentation and guides on how to to do it because we are all here because we are capable of learning things like programming or contributing to KDE. So everybody in this room who can write C++ is also capable of learning Rust. it's more of a a mental thing to unlock uh the desire to to want to learn it or just making sure that people don't refuse to learn out of principle. So I think really educating and giving a low barrier to this education is a way to go. And another thing would probably just be showing people the the benefits of doing that. showing people that hey by using Rust we are able to create software that crashes 90% less or we can do these awesome things. Unfortunately, there will probably still be some people who will just refuse to do any of that out of some sort of principle. But I think that's a problem that we we have regardless of of what we do with anything. And maybe it sometimes the best thing is just to ignore the haters and do our own thing. But it's a very tough balance because as I've tried to get into, there's a lot of legitimate reasons why people might be skeptical of a language like Rust or Python and actually prefer working with C++. One of the challenges regarding the identity and community that I know it's a kind of worms but I have been facing personally facing is that for example the Ras community kind of lives on GitHub and at least from my experience the Python community now is living on discord which I know proprietary software you know the devil and everything but I I think that one of the the the key thing here is that we together we need to think of like what would be the middle point because it will be in my own experience it's impossible for me to be some of the python developers to matrix or IRC and uh similarly with rust I mean every time that I say yeah we can have this thing called gear they said oh what do you mean everything the rust ecosystem is on github so we might need to find together a way of like meeting a middle point so what are your thoughts on on that that topic. >> Yeah. Uh tough topic. Good question. Uh sort of unrelated to the languages specifically because that's just a problem in general that some people expect us to be on on Discord for example. I think one thing we can do is well not outright move to these platforms but offer a good enough alternative. So just making sure we have something relatively modern like matrix and not are stuck to to IRC which would be a much bigger uh obstacle than matrix for example would be and then the other thing is we probably don't want to attract Python developers for the sake of hey you can write Python here instead of there. I think what we really want to do is make sure our product the actual end result is what attracts people into wanting to contribute. And I think if we succeed at that and I think at least a good amount of people is would be willing to not use GitHub and and instead use our GitLab or use Matrix to be able to do that. So I think put the product first and everything else is implementation details. So when talking about community identity in KDE um I remember a few years ago we had a long discussion about the KDE vision KD mission on the KDEV mailing list I think and um yeah I don't know if everybody's aware of the KDE vision so this basically leaves out cute and C++ completely and this was the conclusion of our community back Then maybe if you in case you have internet you could even show it. >> I can say something. Yeah, that is a very good point. Uh, and I definitely agree that leaving specific technologies out of the vision was the right call because as I hinted on earlier, programming languages or frameworks are just implementation details and the end user doesn't care. And if it if the future of KDE means I'm going to write Swift tomorrow, then that's okay with me. if that means we can create awesome software. Um so it's not a question I just want to complete on that and what you just said. Uh so there are three bodies which are basically the the base uh the constitution of KD right so there's the manifesto we worked on and there's like no mention of technology at all. Uh there's the vision, same thing that doesn't mention C++ or cute. There's the mission. In the mission, there's one single mention uh of cute in practice. But no, no, no, let me finish. But the the sentence is interesting. That's basically just somewhere in there saying that to implement the mission, we um we will have the help of KD and other technologies as we see fit basically, right? So yeah, it's I mean from constitution point of view, it's a fairly open field, right? There's no problem there. I'm not very worried about the community identity uh the technical and social fragmentations. That's more and the burden of the complexity of that. That's more where that will be I think >> replicate uh regarding the community identity uh as far as I'm concerned I think it's a lot about freedom itself it's a maybe it's a philosophical question freedom and the responsibility of uh resource management garbage collection um is something where C pure C has lots of wisdom in in it but if you take something from the material world, you have to give it back sooner or later. But Rust at the same time has lots of wisdom about the lifetime of things and when you want to access them. So that's an educational uh aspect of the programming language itself and how it is implemented. So, Swift or whatever language uh probably doesn't care about resource management because they have lots of financial resources to buy expensive uh hardware to handle the shitty software which most people don't have. So, how do you think about this aspect of the language? I have not thought about that. Um I I'm cautious about drawing definitive conclusions about life just from memory management of programming languages. One thing that maybe maybe is more interesting to look at from a community perspective, uh, for example, Rust has done a very good job at not only including but celebrating diversity in their community and diversity of people. And if I think that's something that KD isn't bad at, but maybe something we can also learn from in some ways. Hey. Um, so first of all, thanks for all the good words about the Rust community. I'm the ex lead of the Rust community team. But one of the things I'd like to encourage you is like don't see the Rust community or any programming language community as a solid block. like and in particular a problem when people look at rust is they see the rust project as the community which it isn't and even though the rust project for example meets on zulip for example the rust embedded community meets on matrix like the number of chat channels I have just for that reason in and chat programs is amazing. So the thing I would like to encourage you what is rust at KDE and how can rust at KDE then interact with uh the relevant bits of of Rust. Um I think that's an important model to make. >> Yes, thank you. That is a very good point because there for all the the positivity within the Rust community, there's also less positive aspects of it. Like for example, some parts of the community are extremely zealous about advocacy for Rust and telling everybody if you're not using Rust, you're unsafe, you're legacy, you should be rewritten. And I don't think those parts of the Rust community are doing the overall community a favor by that because I've seen it firsthand in KDE that this has discouraged people from embracing Rust more in some ways. And I think that's sad because there's a lot of positive things to be gained from Rust. And I'm also going to use this as an opportunity to to pitch two things of mine. uh next week during the buffs uh I think on Tuesday I'm going to do a session about diving into some of the more technical details about the rust interperability and how that looks for KD frameworks because I have not shown any code on these slides. So I want to give you the opportunity to take a bit of a peak into what what we have right now and how and I explain a bit how that works and how to contribute to that. And the week after that in Berlin there will be oxidize which is a conference about rust where I will be giving a talk where I'm going to tell the rust people all about the things we are doing in KDE and our somewhat at least unique perspective on on Rust and the future of uh Rust and C++ interrupt. [Music] Uh so why did you choose those two languages to talk about? I mean look at JavaScript. That's where all the developers are and it's already like part of a QML. So one part of that answer is because those are the two most programming language that have the most existing work already in terms of things to build on like Pyite and CXXQ. JavaScript is a bit of an interesting one because as you say we already sort of have that in QML, but I would argue not in a way that is terribly useful because uh first of all a lot of the APIs that exists in cute are not really exposed to that world or exposed in a somewhat limited way. That's something that could be changed, but whether that's the right approach, I don't really know because as things are right now with QML, you have a naturally fairly strict separation between this is the QML UI layer and this is the business logic layer below. That's generally a very good thing. And doing too much JavaScript within QML could jeopardize that. Another aspect is that for example a lot of the JavaScript work that is happening is actually done with languages like TypeScript that build on top of JavaScript. So we have yet another language and system and so on that would need to be incorporated. So it's it's definitely something that I can see working if somebody puts the work into that. It's just not a thing that I have personally chosen to do. But if somebody wants to experiment that and report back they are perfectly welcome to do so. So quickly from the chat um so we had one question which is did you hear about the QT bridges initiative both of those talks for the chat have referenced each other. So we had Christian earlier and then the actual question uh what can be the best approach to use something like bridge or otherwise to build apps with idiomatic rust i.e without interrop quirks with minimal bits of glue cxqt to use existing kd libraries with that. uh if they find out please tell me. I mean one way to approach that from the perspective of people coming into the whole thing is just us creating thicker layers of abstraction and having basically a lot more pre-made idiomatic Rust feeling components that maybe wrap existing C++ code maybe reimplement existing KD concepts like for example Instead of wrapping kconfig C++ API in Rust, we could write a Rust library that just is file format compatible with Kconig and maybe the API would be more idiomatic and nicer to use in Rust. Maybe not. But again, that comes at the cost of doing a lot of more work ourselves and it doesn't necessarily make the whole thing more approachable for people who want to do things that are not yet already covered in existing solutions. So tough question because yeah it it is a very important point that even when you create bindings that does not necessarily create APIs that feel natural and good to the people on the other language side. Awesome. So that is the end of our end of the talk and the end of our day. If we can once again thank Nico. [Applause] Thank you very much everybody.