Concerns Regarding the Choice of Rust for the Xfce Wayland Compositor

Theron York theron.york at cloudnuke.org
Wed Jun 17 17:16:53 CEST 2026


I want to start by saying that I am genuinely excited to see Xfce 
working on a native Wayland compositor. This is an essential step for 
the future of the desktop, and I appreciate the team's effort on this.

However, I have some serious concerns about the decision to write the 
new compositor in Rust. I understand the appeal of memory safety, but I 
think the practical costs are significant and conflict with Xfce's core 
principles.

The first concern is compilation time. Rust is well known for its slow 
compile times, even for incremental builds. This is a real productivity 
hit compared to C, which compiles almost instantly. For a volunteer 
driven project, long build times discourage new contributors and make 
debugging and iteration much more tedious. This is especially 
problematic for users on older or low power hardware, which makes up a 
large part of the Xfce community. The CI infrastructure would also need 
to be upgraded to handle the heavier Rust build load.

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. A compromised crate could execute malicious code during 
the build process. There is also the risk of typosquatting or dependency 
confusion. Xfce has always been trusted because its codebase is 
relatively small and auditable. Adding a sprawling dependency tree makes 
it very difficult for the team to vet everything that ends up in the 
final binary.

Beyond these technical issues, I think this choice goes against the 
traditional Xfce philosophy of keeping things lightweight and 
independent. 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. This 
would give the team total control over the codebase, keep dependencies 
minimal, and ensure the compositor remains lightweight, secure, and easy 
to audit. This approach is entirely viable and would preserve the fast, 
secure, and lean nature that users expect from Xfce.

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.

Thank you for your work on Xfce, and I look forward to hearing your 
thoughts.


-- 
------------------------------------------------------------------------

/"I believe that a sane world is a world with only free software."/

*Theron York*
CloudNuke
cloudnuke.org <https://cloudnuke.org>
theron.york at cloudnuke.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20260617/440f9f91/attachment.htm>


More information about the Xfce4-dev mailing list