Theron,<div><br></div><div>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.</div><div><br></div><div>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: <a href="https://nnethercote.github.io/perf-book/compile-times.html" style="word-break: break-word;" target="_blank" rel="noreferrer nofollow noopener">https://nnethercote.github.io/perf-book/compile-times.html</a></div><div><br></div><div>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.: <a href="https://rustsec.org/" target="_blank" rel="noreferrer nofollow noopener">https://rustsec.org/</a></div><div><br></div><div>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.</div><div><br></div><div>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! :)</div><div><br></div><div>Cheers,</div><div>Barrett Ray</div><div><br></div><div><br><br><br><div class="protonmail_signature_block-user"></div><br><br></div><br><div class="protonmail_quote"><br><br>-------- Original Message --------<br>On Wednesday, 06/17/26 at 10:17 Theron York <<a href="mailto:theron.york@cloudnuke.org" rel="noreferrer nofollow noopener">theron.york@cloudnuke.org</a>> wrote:<br><blockquote class="protonmail_quote">
<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" rel="noreferrer nofollow noopener" target="_blank">cloudnuke.org</a><br>
<a href="mailto:theron.york@cloudnuke.org" class="moz-txt-link-freetext" rel="noreferrer nofollow noopener">theron.york@cloudnuke.org</a>
</p>
</div>
</blockquote></div>