Concerns Regarding the Choice of Rust for the Xfce Wayland Compositor
Theron York <[email protected]> Wed, 17 Jun 2026 10:16:53 -0500
| Newsgroups | gmane.comp.desktop.xfce.devel.version4 |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============7254192237247638227== Content-Type: multipart/alternative; boundary="------------rb0AP3RdDiNAvaoVUUEeR0Ra" Content-Language: en-US This is a multi-part message in MIME format. --------------rb0AP3RdDiNAvaoVUUEeR0Ra Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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> [email protected] --------------rb0AP3RdDiNAvaoVUUEeR0Ra Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <!DOCTYPE html> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body> <p dir="auto">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.</p> <p dir="auto">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.</p> <p dir="auto">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.</p> <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. 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.</p> <p dir="auto">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.</p> <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> <p dir="auto">Thank you for your work on Xfce, and I look forward to hearing your thoughts.</p> <p><br> </p> <div class="moz-signature">-- <br> <hr> <p><em>"I believe that a sane world is a world with only free software."</em></p> <p> <strong>Theron York</strong><br> CloudNuke<br> <a href="https://cloudnuke.org">cloudnuke.org</a><br> <a href="mailto:[email protected]" class="moz-txt-link-freetext">[email protected]</a> </p> </div> </body> </html> --------------rb0AP3RdDiNAvaoVUUEeR0Ra-- --===============7254192237247638227== 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 --===============7254192237247638227==--