Concerns Regarding the Choice of Rust for the Xfce Wayland Compositor

[Mailing Lists]

Theron,
I'm also interested in discussing that choice, though I want to note that I'm more or less indifferent to the choice of language.

Incremental compilation times in modern Rust are much lower than they used to be, though first-time builds (i.e., those prior ti generating the `target/` cache) are still somewhat higher than C. The main ways to reduce first-time build times include: reducing generics usage in functions and types, limiting macro usage, replacing procedural macros with code generation or declarative macros, and cutting dependency trees. As you'll note, the vast majority of these are related to code generation and inclusion; that's slow in any language -- not just Rust. It's more of a style/fundamentals problem, like in C++. See: https://nnethercote.github.io/perf-book/compile-times.html

Your next concern is very significant, and I strongly advise maintainers to abide by a strong security policy. Please vendor your dependencies, limit library reliance, and vet everything carefully! Any Crates.io libraries should be locked via `Cargo.lock` s.t. reproducible builds would be required from the very start. Monitor RustSec advisories and patch any affected or vendored dependencies as soon as possible. You may also wish to use tools like `cargo-deny` to automatically scan dependencies for RustSec advisories, licensing problems, etc.: https://rustsec.org/

I would also encourage Xfce maintainers to explore more "home-made" solutions, though I don't necessarily believe it should be in C. From what I've seen, C-based compositors get to be a bit of a mess internally, and Rust can help there by enforcing its many static guarantees! It's just a matter of writing and adopting strategies for risk management, especially for ecosystem security. I also strongly advise that y'all adopt human-focused security guidelines, meaning that LLMs shouldn't be trusted to generate secure source code. Please keep humans in the loop at all times -- `rustc` can detect many memory safety mistakes, but LLMs bring many additional security problems and tend to bloat codebases.

I agree with your request for a security audit of Smithay and its dependencies, hopefully resulting in either a full dependency lock or in-tree/vendored crates. Hope to see something on that soon! :)

Cheers,
Barrett Ray










-------- Original Message --------
On Wednesday, 06/17/26 at 10:17 Theron York <theron.york at cloudnuke.org> wrote:

> 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
> theron.york at cloudnuke.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20260617/44b068fd/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - koemail at protonmail.com - 0xA3BCBAE4.asc
Type: application/pgp-keys
Size: 659 bytes
Desc: not available
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20260617/44b068fd/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20260617/44b068fd/attachment.sig>