<!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 wrote:</div><blockquote type="cite" id="qt" style=""><p dir="auto">The first concern is compilation time. Rust is well
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 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.</div><div><br></div><blockquote type="cite"><div>long build times discourage new contributors and make debugging and iteration 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 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.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite" id="qt" style=""><div dir="auto">The CI infrastructure would also need to be upgraded to
handle the heavier Rust build load.</div></blockquote><div><br></div><div>The CI infrastructure has been building xfwl4 just fine over the past 5-6 months; no upgrades are needed.</div><div><br></div><blockquote type="cite" id="qt" style=""><p dir="auto">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.</p></blockquote><div><br></div><div>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.</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 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.)</div><div><br></div><blockquote type="cite" id="qt" style=""><div dir="auto">Xfce
has always been trusted because its codebase is relatively small
and auditable.</div></blockquote><div><br></div><div>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.</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 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.</div><div><br></div><blockquote type="cite" id="qt" style=""><div dir="auto"> Adding a sprawling dependency tree makes it very
difficult for the team to vet everything that ends up in the final
binary.</div></blockquote><div><br></div><div>Given that the existing C dependencies haven't been vetted in any meaningful way, I don't think this changes much.</div><div><br></div><blockquote type="cite" id="qt" style=""><p dir="auto">Beyond these technical issues, I think this choice
goes against the traditional Xfce philosophy of keeping things
lightweight and independent.</p></blockquote><div><br></div><div>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.)</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 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.</div><div><br></div><blockquote type="cite" id="qt" style=""><div dir="auto">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.</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 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.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite" id="qt" style=""><div dir="auto"> This would give the team total
control over the codebase</div></blockquote><div><br></div><div>This is not realistic. No team has "total control" over any code base or its dependencies.</div><div><br></div><blockquote type="cite" id="qt" style=""><div dir="auto">keep dependencies minimal, and ensure
the compositor remains lightweight, secure, and easy to audit.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>And again, no one has been doing security audits of Xfce or its C-based dependencies, so using Rust does not change that situation.</div><div><br></div><blockquote type="cite" id="qt" style=""><div dir="auto">This approach is entirely viable and would preserve the fast,
secure, and lean nature that users expect from Xfce.</div></blockquote><div><br></div><div>Building xfwl4 in Rust also preserves those properties.<br></div><div><br></div><blockquote type="cite" id="qt" style=""><p dir="auto">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.</p></blockquote><div><br></div><div>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. </div><div><br></div><div>At any rate, xfwl4 is going to have its first preview release soon, and I see no reason to change course on this.</div><div><br></div><div>Regards,</div><div>Brian</div></body></html>