On Tue, Jul 22, 2025 at 04:56:12PM +0100, Sam James wrote: > There's a few issues from our perspective: > > * Old platforms which don't have LLVM can't yet have Rust either, as > rustc is based on LLVM. > > These need gccrs to be unblocked. I can understand not caring too much > about these, though it is unfortunate, because I think if git hadn't > supported many platforms to begin with, I doubt it'd have the adoption > it does today. > > (There is another effort which seeks to take rustc and bolt on > libgccjit as a replacement backend, but that isn't feasible for use > yet either.) It would be great to know about the general timelines of these alternative implementations. If e.g. gccrs were to achieve compatibility with one of the editions of Rust next year it would be a good enough reason to defer the rustification from my point of view so that we don't break the ecosystem and have wider platform support. If the answer is "They'll land in 10 years" then I don't know... I sifted through their project sites and found various status reports, and they do seem to be making steady progress. But as far as I see critical language features are still missing as of now. [snip] > * rustc doesn't have LTS releases or the like. > > The only supported release is the latest one. Upgrading to the latest > release often means we have to deal with new portability problems > but we can't not upgrade because: > a) some software will start to require bleeding-edge Rust immediately, > and > b) it means we're missing out on bug fixes (miscompilations are > serious) I'm not a big fan of this in the Rust ecosystem indeed. It feels like every second project requires nightly features or at least a version of the compiler that was released in the last couple months. This may work for a language like Go, which is more targeted towards deploying server applications. But for a system-level language like Rust I think it's rather a sign of it being immature. In any case, the burden would fall on us to ensure that we carefully consider which version of Rust to target. And as it was said elsewhere in the thread, we would need to make sure that things build on old versions of Debian. Which may be easier said than done if we also rely on lots of crates which may update to newer Rust versions at any point in time. > * Crate creep > > Rust projects tend to end up having a huge list of crates that they > pull-in which makes us worried about something nasty creeping in, but > there's also popular crates with serious portability problems like the > 'ring' crate for TLS. True. I think if we were to adopt Rust we ought to be as conservative as we are now with picking up new dependencies. I don't want to have a big open door for supply chain attacks. And neither do I want to be forced into the situation where we cannot update a crate because they decided to drop support for older Rust versions. Patrick
