On 2025-09-03 at 05:40:54, Patrick Steinhardt wrote: > If I had the choice, I'd much rather adopt an ancient version of Rust if > it means that more platforms can support it. I think you may be assuming that gccrs targeting Rust 1.49 will magically make it work on more platforms than upstream Rust will. That's not the case. gccrs targeting Rust 1.49 will use libstd (the standard library) and libcore (the library for freestanding implementations) from Rust 1.49 and that means it will only support those platforms that Rust 1.49 did. For instance, Rust added support for Apache NuttX relatively recently. Even if it has stellar support in GCC, it won't work with that version of gccrs because the underlying libraries don't support any of those platforms. The only thing you can target that you couldn't before are systems that use neither libstd nor libcore—which essentially means the Linux kernel. It's like using a glibc from 2009 and expecting to work on RISC-V—it simply won't[0]. If you need support for new platforms, that requires a much _newer_ version of Rust. Thus, to be able to use gccrs, porters need to use the existing gcc codegen backend and get that code in immediately so that when gccrs is out and supports Rust 1.91, the standard library will work with those platforms. The fastest way to getting platforms supported is to port LLVM and then add them to upstream Rust that way. I know there has been much complaint about the six-week lifespan of Rust releases. I myself dislike that. But the situation is that LTS releases require extensive amounts of work and nobody has stepped up to do that or pay for it to be done. Without dedicated staffing, it's not going to happen. That also means that individual projects decide what versions of Rust they do and don't want to support. We're already supporting the version in Debian stable for a year after the new release comes out, so we're already far behind what everyone else is doing. For comparison, Rust 1.48 is in Debian 11, so we'd be supporting an effectively five-year-old compiler instead of a three-year-old compiler. Requiring Rust 1.49 instead of Rust 1.63 makes it harder to use tools like bindgen and cbindgen, which exist to automatically create types and functions in one language in the other. That, in turn, will hinder our ability to effectively write code that crosses the boundary and introduce hard-to-find bugs, since we'll have to do that work manually. My experience is that these kinds of bugs tend to actually show up more frequently on less common platforms, like big-endian systems, so we'll be worsening the platform experience for those systems. For context, when we ported a core service from C to Rust at work, we used bindgen to generate C struct definitions, which made the process much easier and avoided random crashes. As a result, nobody noticed the fact that we ported it incrementally over a couple of years. If we hadn't used bindgen, we probably would have had lots of random segfaults due to failing to maintain compatibility between Rust and C definitions of the same structures, which users would not have appreciated and would not have helped our goal of making our software more reliable and easier to maintain. > The gccrs maintainers are actively working on that backend, and as far > as I understand the main difference between LLVM and gccrs is that the > latter doesn't have to be ported over to every single platform > individually. I don't think that's the case. gccrs has to be compiled for every platform just like LLVM does. LLVM is actually easier to support because it can cross-compile from any platform to any platform without recompilation. For instance, I can target riscv64gc-unknown-openbsd on my Debian amd64 laptop assuming I can provide the necessary libraries for OpenBSD when compiling, but GCC requires me to specifically compile a compiler for that platform. In any event, any portability changes will also likely need to go into libstd and libcore, which is used identically with both compilers. It is, however, the case that GCC supports more architectures (and possibly more architecture/OS combinations) than LLVM. For instance, DEC Alpha and IA64 are only supported by GCC at the moment. > I think adopting Rust as a mandatory dependency out of nowhere would not > be playing nice. It may require significant effort from distros to adapt > to the new reality, so we should give them time to do so. We've actually had this discussion on the list several times where we've proposed the inclusion of Rust. This is not the first time it's come up, or the second. It was explicitly mentioned a year ago on the list that we wanted to adopt Rust in the notes from the Contributor Summit. There has been plenty of notice that this is coming down the line. It's not accurate to claim it's "out of nowhere" nor to claim that people have not had plenty of time to port their systems. Distros and porters should not be insensible to the increasing use of Rust or the need for them to get their systems working. For instance, you cannot run a GNOME or MATE desktop environment without librsvg2, which is written in Rust. Python's cryptography package adopted Rust over four years ago and there was the same gnashing of teeth[1], yet little progress has been made by porters on the same affected architectures since that time. In that time, Debian has bootstrapped and released an entire RISC-V port, complete with Rust. I want to be clear I'm not opposed to supporting less common operating systems or architectures. For many years, my laptop was a PowerPC Mac, and I've owned UltraSPARC, MIPS, and ARM hardware. For personal code, I try to test it in CI on at least Linux, macOS, FreeBSD, and NetBSD. But also, when a Debian package has not worked properly on PowerPC or UltraSPARC, I've stepped up and fixed it. My requests to other projects when porting have been things like asking to write valid C or C++ (by not making unaligned accesses or avoiding endianness assumptions, for instance) and not to refrain from adding new languages or features. It should be stated that there is a very easy way to get Rust working, and that's to port LLVM to the platform in question. IA-64 was removed in 2009, but it might be possible to resurrect that out of tree if there's interest and maybe even get it re-accepted upstream. I'll point out that AIX, Solaris, and QNX have done the necessary porting work to get LLVM and Rust working over the past couple years, so it's not out of the question for other platforms to do so as well. And, for the avoidance of doubt, I would be absolutely delighted if we were able to support additional platforms with Rust as well. Also, the approach of making it an optional component directly contradicts the proposed policy I wrote up. That's a recipe for additional burdensome work maintaining two implementations, when we actually want to make it easier for people to contribute functionality. It also doesn't provide any of the memory safety benefits or address any of the concerns from governments, security professionals, and other parties about the real and substantial risks of continuing to develop in C. For example, there is zero chance I will implement any of the SHA-1/SHA-256 compatibility code twice. I'm already doing that in my free time without any compensation at all and it's unreasonable to expect me to do it twice or even to #ifdef out all the places it would need to go. I am happy to let someone else take responsibility for the project instead, however, if they would like to do those things. > It would be a shame, but right now it's a risky bet to build anything on > top of Rust given that we don't officially accept it in Git yet. We need > to first make the decision whether or not we want to have it right now, > and if so how that's supposed to look like. I think we had made the decision at the 2024 Contributor's Summit that we wanted to adopt Rust in Git, so it was more of a matter of sending the patches than actually making that decision. As I recall, the decision was unanimous. [0] RISC-V was developed in 2010. [1] https://www.reddit.com/r/rust/comments/lfysy9/pythons_cryptography_package_introduced_build/ -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
