Re: Concerns Regarding the Choice of Rust for the Xfce Wayland Compositor
"Brian Tarricone" <[email protected]> Wed, 17 Jun 2026 12:39:15 -0700
| Newsgroups | gmane.comp.desktop.xfce.devel.version4 |
|---|---|
| Message-ID | <[email protected]> |
--===============3407300540256381774== Content-Type: multipart/alternative; boundary=9255e6c2569a6dab7fee75330bc196730aefc436 --9255e6c2569a6dab7fee75330bc196730aefc436 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Theron, On Wed, Jun 17, 2026, at 08:16, Theron York wrote: > The first concern is compilation time. Rust is well known for its slow compile times, even for incremental builds. > Agreed in general, though I don't think I'd agree that incremental builds are that bad. Certainly an incremental build of xfwl4 (that only recompiles xfwl4's code itself) is slower than many C builds, but I don't think the time is a huge burden. I've done incremental builds of it thousands of times at this point, and while I wouldn't say I love how long it takes, it's tolerable, and hasn't been an impediment to my work. > long build times discourage new contributors and make debugging and iteration much more tedious. I'm not sure I buy the first part of that. I'd think "I don't know Rust and I'm not interested in learning it" would be a bigger issue. And I don't find debugging and iteration more tedious due to slow compile times. Also given that successful compilation gives me more confidence and guarantees of (certain types of) correctness than a successfully C program compilation, debugging and iteration cycles are fewer in number. At any rate, this is a purely subjective measure and issue. I get that you personally perhaps find this to be a serious showstopper of a problem, but many people won't. And on top of that, the Rust compiler team works on performance issues; often compilation performance gets better by merely updating to a new version of the compiler. > The CI infrastructure would also need to be upgraded to handle the heavier Rust build load. The CI infrastructure has been building xfwl4 just fine over the past 5-6 months; no upgrades are needed. > The second concern is the supply chain risk from Cargo and crates.io. Using Rust means pulling in a large number of external dependencies, which introduces a significant attack surface that does not exist in a pure C project. > This is absolutely true, and is the one and only thing that worries me about using Rust. I'm not sure what the solution is here, if there is one. Both smithay and gtk-rs pull in quite a lot of transitive dependencies, and there's not much that can be done about that. I think software ecosystems as a whole are only just starting to figure out what to do about supply chain issues around centralized dependency managers, and there's still a lot of work to be done to increase security and confidence. One potential benefit we have here is distro packagers: most of our users do not compile and run Xfce from source. They use packages built by their distro. Debian (which includes Ubuntu/Xubuntu), for example, does not pull packages from crates.io on every build. They package the source of each crate, and Rust application builds point to a local cargo registry to find dependencies. This does suffer from the "trust on first use" problem, and I don't know what Debian does to vet initial package creation or later version updates. But this does feel safer than pulling from crates.io on every single build (or blindly running 'cargo update' and ignoring its output). Users who care about this sort of thing should be using a distro that also cares about this sort of thing. (And if they aren' t, then they have bigger issues than Xfce's compositor.) > Xfce has always been trusted because its codebase is relatively small and auditable. This feels like a bit of a stretch to me. Do people really think about Xfce in these terms? At any rate, a quick check with 'cloc' shows the core components of Xfce include around 450,000 lines of C code. That doesn't include other core-adjacent apps that most people will run (xfce4-notifyd, xfce4-appfinder, etc.) and any panel plugins outside the core included with xfce4-panel. GTK and its major dependencies amount for another whopping 1,270,000 lines of C code. I'm not considering any of the X11 libraries or other dependencies like libyaml, libupower, libudev, etc., but I expect they're not insignificant. Even with just what I've counted, that's more than 1.7M lines of code, and with other dependencies and apps, I'm sure it's well above 2M. I think it's safe to assume no one has audited all that code, and that no one plans to. Xfce is not small from a code perspective, and I don't think auditability of Rust dependencies is a valid criticism here given the status quo. > Adding a sprawling dependency tree makes it very difficult for the team to vet everything that ends up in the final binary. Given that the existing C dependencies haven't been vetted in any meaningful way, I don't think this changes much. > Beyond these technical issues, I think this choice goes against the traditional Xfce philosophy of keeping things lightweight and independent. > I don't think you're interpreting "lightweight" in the way that the Xfce team has over the years. It's about using system resources (memory and CPU, mostly) sparingly _at runtime_. It says nothing about the use of language to build Xfce, or what its toolchain is like. (And I think this is the correct interpretation, and is what actually matters to users.) I'm not sure what you mean about "independent"; that's never been a part of the Xfce philosophy, and I'm not sure what that means in general. Depending on the Rust compiler is no different from depending on a C compiler, and depending on smithay or gtk-rs is no different from depending on libgtk3 or libX11 or an X server. > Instead of adopting a new language and ecosystem, I would urge the team to implement the compositor in C using a custom in house approach, just as Xfce has always done for its core components. Not sure what you mean by "custom in house" approach: Xfce does not do that. Xfce depends on GTK, a massive C library (>1M lines of code). Should Xfce implement a custom, in house widget library? Of course not. Where do you draw the line? It's a completely subjective choice, and Xfce is run by a small team of volunteers who do not have the time or resources to build and manage these sorts of dependencies. If Xfce were to have a compositor built in C, it would absolutely use wlroots (another ~100k lines of C). Xfce would certainly not go the GNOME or KDE route of building the compositor completely from scratch. > This would give the team total control over the codebase This is not realistic. No team has "total control" over any code base or its dependencies. > keep dependencies minimal, and ensure the compositor remains lightweight, secure, and easy to audit. The compositor *is* lightweight, as measured at runtime, or will be, once I've worked on that aspect of it more closely. A C-based compositor would not be any different in this regard. And again, no one has been doing security audits of Xfce or its C-based dependencies, so using Rust does not change that situation. > This approach is entirely viable and would preserve the fast, secure, and lean nature that users expect from Xfce. Building xfwl4 in Rust also preserves those properties. > I respect the decision to look at Rust for safety, likely via smithay, but I believe the trade offs are too large. I would kindly ask the team to publicly address these concerns and reconsider the language choice. > I hope you feel that these concerns have been addressed. Even if you don't agree with all of my conclusions, I hope you can at least admit that most of your concerns are subjective, and that there's no right or wrong answers for them. At any rate, xfwl4 is going to have its first preview release soon, and I see no reason to change course on this. Regards, Brian --9255e6c2569a6dab7fee75330bc196730aefc436 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><head><title></title></head><body><div>Hi Theron,</= div><div><br></div><div>On Wed, Jun 17, 2026, at 08:16, Theron York wrot= e:</div><blockquote type=3D"cite" id=3D"qt" style=3D""><p dir=3D"auto">T= he first concern is compilation time. Rust is well=0A known for its= slow compile times, even for incremental builds.</p></blockquote><div><= br></div><div>Agreed in general, though I don't think I'd agree that inc= remental builds are that bad. Certainly an incremental build of xf= wl4 (that only recompiles xfwl4's code itself) is slower than many C bui= lds, but I don't think the time is a huge burden. I've done increm= ental builds of it thousands of times at this point, and while I wouldn'= t say I love how long it takes, it's tolerable, and hasn't been an imped= iment to my work.</div><div><br></div><blockquote type=3D"cite"><div>lon= g build times discourage new contributors and make debugging and iterati= on much more tedious.<br></div></blockquote><div><br></div><div>I'm not = sure I buy the first part of that. I'd think "I don't know Rust an= d I'm not interested in learning it" would be a bigger issue. And = I don't find debugging and iteration more tedious due to slow compile ti= mes. Also given that successful compilation gives me more confiden= ce and guarantees of (certain types of) correctness than a successfully = C program compilation, debugging and iteration cycles are fewer in numbe= r.</div><div><br></div><div>At any rate, this is a purely subjective mea= sure and issue. I get that you personally perhaps find this to be = a serious showstopper of a problem, but many people won't. And on = top of that, the Rust compiler team works on performance issues; often c= ompilation performance gets better by merely updating to a new version o= f the compiler.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" = style=3D""><div dir=3D"auto">The CI infrastructure would also need to be= upgraded to=0A handle the heavier Rust build load.</div></blockquo= te><div><br></div><div>The CI infrastructure has been building xfwl4 jus= t fine over the past 5-6 months; no upgrades are needed.</div><div><br><= /div><blockquote type=3D"cite" id=3D"qt" style=3D""><p dir=3D"auto">The = second concern is the supply chain risk from Cargo=0A and crates.io= . Using Rust means pulling in a large number of=0A external depende= ncies, which introduces a significant attack=0A surface that does n= ot exist in a pure C project.</p></blockquote><div><br></div><div>This i= s absolutely true, and is the one and only thing that worries me about u= sing Rust. I'm not sure what the solution is here, if there is one= . Both smithay and gtk-rs pull in quite a lot of transitive depend= encies, and there's not much that can be done about that. I think = software ecosystems as a whole are only just starting to figure out what= to do about supply chain issues around centralized dependency managers,= and there's still a lot of work to be done to increase security and con= fidence.</div><div><br></div><div>One potential benefit we have here is = distro packagers: most of our users do not compile and run Xfce from sou= rce. They use packages built by their distro. Debian (which = includes Ubuntu/Xubuntu), for example, does not pull packages from crate= s.io on every build. They package the source of each crate, and Ru= st application builds point to a local cargo registry to find dependenci= es. This does suffer from the "trust on first use" problem, and I = don't know what Debian does to vet initial package creation or later ver= sion updates. But this does feel safer than pulling from crates.io= on every single build (or blindly running 'cargo update' and ignoring i= ts output). Users who care about this sort of thing should be usin= g a distro that also cares about this sort of thing. (And if they = aren't, then they have bigger issues than Xfce's compositor.)</div><div>= <br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"aut= o">Xfce=0A has always been trusted because its codebase is relative= ly small=0A and auditable.</div></blockquote><div><br></div><div>Th= is feels like a bit of a stretch to me. Do people really think abo= ut Xfce in these terms? At any rate, a quick check with 'cloc' sho= ws the core components of Xfce include around 450,000 lines of C code.&n= bsp; That doesn't include other core-adjacent apps that most people will= run (xfce4-notifyd, xfce4-appfinder, etc.) and any panel plugins outsid= e the core included with xfce4-panel. GTK and its major dependenci= es amount for another whopping 1,270,000 lines of C code. I'm not = considering any of the X11 libraries or other dependencies like libyaml,= libupower, libudev, etc., but I expect they're not insignificant.</div>= <div><br></div><div>Even with just what I've counted, that's more than 1= .7M lines of code, and with other dependencies and apps, I'm sure it's w= ell above 2M. I think it's safe to assume no one has audited all t= hat code, and that no one plans to. Xfce is not small from a code = perspective, and I don't think auditability of Rust dependencies i= s a valid criticism here given the status quo.</div><div><br></div><bloc= kquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"auto"> Adding a sp= rawling dependency tree makes it very=0A difficult for the team to = vet everything that ends up in the final=0A binary.</div></blockquo= te><div><br></div><div>Given that the existing C dependencies haven't be= en vetted in any meaningful way, I don't think this changes much.</div><= div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><p dir=3D"a= uto">Beyond these technical issues, I think this choice=0A goes aga= inst the traditional Xfce philosophy of keeping things=0A lightweig= ht and independent.</p></blockquote><div><br></div><div>I don't think yo= u're interpreting "lightweight" in the way that the Xfce team has over t= he years. It's about using system resources (memory and CPU, mostl= y) sparingly _at runtime_. It says nothing about the use of langua= ge to build Xfce, or what its toolchain is like. (And I think this= is the correct interpretation, and is what actually matters to users.)<= /div><div><br></div><div>I'm not sure what you mean about "independent";= that's never been a part of the Xfce philosophy, and I'm not sure what = that means in general. Depending on the Rust compiler is no differ= ent from depending on a C compiler, and depending on smithay or gtk-rs i= s no different from depending on libgtk3 or libX11 or an X server.</div>= <div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D= "auto">Instead of adopting a new language=0A and ecosystem, I would= urge the team to implement the compositor=0A in C using a custom i= n house approach, just as Xfce has always=0A done for its core comp= onents.</div></blockquote><div><br></div><div>Not sure what you mean by = "custom in house" approach: Xfce does not do that. Xfce depends on= GTK, a massive C library (>1M lines of code). Should Xfce impl= ement a custom, in house widget library? Of course not. Wher= e do you draw the line? It's a completely subjective choice, and X= fce is run by a small team of volunteers who do not have the time or res= ources to build and manage these sorts of dependencies.</div><div><br></= div><div>If Xfce were to have a compositor built in C, it would absolute= ly use wlroots (another ~100k lines of C). Xfce would certainly no= t go the GNOME or KDE route of building the compositor completely from s= cratch.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D= ""><div dir=3D"auto"> This would give the team total=0A control ove= r the codebase</div></blockquote><div><br></div><div>This is not realist= ic. No team has "total control" over any code base or its dependen= cies.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""= ><div dir=3D"auto">keep dependencies minimal, and ensure=0A the com= positor remains lightweight, secure, and easy to audit.</div></blockquot= e><div><br></div><div>The compositor *is* lightweight, as measured at ru= ntime, or will be, once I've worked on that aspect of it more closely.&n= bsp; A C-based compositor would not be any different in this regard.</di= v><div><br></div><div>And again, no one has been doing security audits o= f Xfce or its C-based dependencies, so using Rust does not change that s= ituation.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D= ""><div dir=3D"auto">This approach is entirely viable and would preserve= the fast,=0A secure, and lean nature that users expect from Xfce.<= /div></blockquote><div><br></div><div>Building xfwl4 in Rust also preser= ves those properties.<br></div><div><br></div><blockquote type=3D"cite" = id=3D"qt" style=3D""><p dir=3D"auto">I respect the decision to look at R= ust for safety,=0A likely via smithay, but I believe the trade offs= are too large. I=0A would kindly ask the team to publicly address = these concerns and=0A reconsider the language choice.</p></blockquo= te><div><br></div><div>I hope you feel that these concerns have been add= ressed. Even if you don't agree with all of my conclusions, I hope= you can at least admit that most of your concerns are subjective, and t= hat there's no right or wrong answers for them. </div><div><br></div><di= v>At any rate, xfwl4 is going to have its first preview release soon, an= d I see no reason to change course on this.</div><div><br></div><div>Reg= ards,</div><div>Brian</div></body></html> --9255e6c2569a6dab7fee75330bc196730aefc436-- --===============3407300540256381774== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xfce4-dev mailing list [email protected] https://mail.xfce.org/mailman/listinfo/xfce4-dev --===============3407300540256381774==--