But why
But why
Posted Oct 1, 2024 22:50 UTC (Tue) by sam_c (subscriber, #139836)In reply to: But why by hunger
Parent article: An update on gccrs development
It's very common for applications to depend on very new (just-released) versions of Rust. It's also common for flagship Rust applications like Firefox to rely heavily on "unstable" features and break on new Rust releases -- which always makes me ask why, if something as important as Firefox needs it, something hasn't been resolved yet.
Posted Oct 1, 2024 23:01 UTC (Tue)
by josh (subscriber, #17465)
[Link] (2 responses)
No, it indicates that Rust for Linux is still in development and that some of the specific features Rust for Linux needs are still in development.
> It's also common for flagship Rust applications like Firefox to rely heavily on "unstable" features and break on new Rust releases
To the best of my knowledge, Firefox has not needed that for a long time. That perception was created by one particular crate in Firefox's dependency tree that, without coordination with the rest of the ecosystem, forcibly opted the entire build into nightly-only features in order to use SIMD for acceleration. That crate no longer does so, but the reputation damage that crate did still remains to this day.
Posted Oct 1, 2024 23:09 UTC (Tue)
by sam_c (subscriber, #139836)
[Link] (1 responses)
I think it's easy for me to make the conclusion I did when Rust as an ecosystem has several prominent packages which need nightly crates?
If it's several and not limited to a specific domain (like just Rust for Linux), it's hard for me to *not* make that conclusion?
> That perception was created by one particular crate in Firefox's dependency tree that, without coordination with the rest of the ecosystem, forcibly opted the entire build into nightly-only features in order to use SIMD for acceleration.
It looks like the last time it broke in FF was packed_simd in Rust 1.78 (many times before that). I hope it is indeed fixed now, but I would say that May from this year isn't a long time ago.
Posted Oct 4, 2024 9:57 UTC (Fri)
by josh (subscriber, #17465)
[Link]
That's news to me; sorry to hear that. I would not have said it was a long time ago if I'd known about the break in 1.78.
Posted Oct 2, 2024 1:41 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (9 responses)
Or maybe it indicates that Rust-for-Linux is an incredibly special case (for multitude of reasons, the main of which is the need to integrate into an existing giant, very low-level C project), and it's very specifically support for _that_ special case which isn't mature?
Posted Oct 2, 2024 2:33 UTC (Wed)
by sam_c (subscriber, #139836)
[Link] (8 responses)
Posted Oct 2, 2024 10:49 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (7 responses)
To me that suggests that you've extrapolated wildly rather than actually having "a lot" of these cases.
Posted Oct 2, 2024 17:53 UTC (Wed)
by sam_c (subscriber, #139836)
[Link] (6 responses)
I already gave evidence that it wasn't faulty at all -- it happened in May for Firefox. We had an issue with rustls' build.rs needing nightly in March (they were happy to fix it though). For a long time, 'eww' (not the Emacs one) required nightly but they fixed that in Feb. Chromium requires nightly features (at least for various -Z ... flags it passed) at the moment. Those are examples I've hit personally and that I can easily recall, and I don't represent all developers in our distro.
Posted Oct 2, 2024 17:54 UTC (Wed)
by sam_c (subscriber, #139836)
[Link]
(My point being that others mention such cases as well, I just don't remember the package names without checking logs.)
Posted Oct 3, 2024 8:33 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
How confident are you that every single C and C++ program that's packaged has all the correct feature tests for the features it depends on? Both languages do notionally provide these tests. I've never used them. My guess is that actually very few even try and that the feature tests which are present in the rest are often faulty, so long as the code builds and seems superficially to work on popular platforms that's enough.
Posted Oct 4, 2024 3:28 UTC (Fri)
by sam_c (subscriber, #139836)
[Link] (3 responses)
I didn't even say "it's not mature", I said it indicates to me that it isn't yet - very much about my perception and open to discussion, which is why I'm commenting at all...
> How confident are you that every single C and C++ program that's packaged has all the correct feature tests for the features it depends on?
I spent a lot of time on this sort of thing last year, which LWN wrote about. Not very confident at all! But my point was and remains that if Rust is mature, I'd expect use in the kernel to not need heaps of nightly features. It comes across as odd to me because if Rust is deployed widely in kernel-like environments, surely this kind of functionality should be worked out already?
Posted Oct 4, 2024 13:03 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link]
That would depend what "this kind of functionality means". For example Linux really can't abide floating point, so for them it's crucial that you can't by any means end up doing floating point operations in Rust for Linux unless you've spelled out that intent very clearly. Unsurprisingly in most applications it's enough that (as is true in stable Rust) you don't stumble onto floating point operations when you never needed them. For example in Rust, just as in C, 5 / 2 is 2 because it's not performing a floating point divide and then transmuting the type as it would in say, Python.
So to adjust from "Yeah, so don't do that" to "We'll make sure you won't do that" Rust for Linux needed tweaks and the stable Rust does not have those tweaks.
Are you astonished that nobody else had this requirement? Nobody in embedded cares, most of the other operating systems are not in a place where "enforce micro-optimisation of context switch overhead" is a focus. If there are people who care (maybe at Microsoft?), and are using Rust for the OS kernel, they're not advertising this use.
In 2023 you could point at alloc, back then Rust for Linux relied on a fork of alloc because Linus requires that allocations are fallible at the point of use, which means all the Rust APIs which panic on allocation failure must be removed from Rust for Linux. Rust's core does not allocate - it doesn't have an allocator so it can't, and Rust's std layer requires an operating system so it will never be part of Rust for Linux - we're implementing the OS not using it. But alloc was in the middle, and so for a period Rust for Linux forked it. That's done, the stable Rust ships all the explicit allocation failure stuff which Linus insists on.
But actually in alloc we do see things where (I did not check specifics) Rust for Linux might want them but they aren't in stable Rust today. Vec::push_within_capacity for example. In C you'd just use it and YOLO. In Rust that will not work† and you must ask for nightly Rust if you want these features.
† You could use Mara's nighty_crimes! macro or write your own, but that's not a serious suggestion and in practice amounts to the same thing.
Posted Oct 6, 2024 22:55 UTC (Sun)
by raven667 (subscriber, #5198)
[Link] (1 responses)
I think this whole effort _is_ the process by which the specific changes needed for Rust to support the existing Linux kernel (rather than a custom all-Rust kernel or userspace application) become mature, Rust is clearly capable of it, the clock for stability _starts_ when the implementation of Rust is ready, but it's only marked as "stable" after some time of real-world use. A half-thought-through analogy is that some special vintage wine is the same liquid put in the bottle the day it was made, when it wasn't special, but time and some tiny changes made it special later, a feature might land in nightly but with time and some tiny changes it becomes stable infrastructure, but it was substantially there the day it was made in nightly. Rust for Linux is going to take several more years to all come together and be seen as old-and-stable, but that is the trend.
Posted Oct 7, 2024 14:13 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
You can describe several milestones of maturity, Rust as a mature standalone application development language, Rust maturity for mixed C/C++ applications and library development, Rust maturity building a standalone kernel, Rust used in some generic mixed C/C++ kernels and Rust for Linux the specifically fits in with the internal style and abstractions of Linux. People can end up talking past one another a bit by not being clear as to what they are referring to.
Posted Oct 11, 2024 9:28 UTC (Fri)
by moltonel (subscriber, #45207)
[Link]
That's in large part "because we can", not because older versions are buggy or unusable. Installing the latest or multiple versions is trivial with rustup, and compatibility is usually perfect (notwithstanding the recent 1.80 time mess). So some developers might jump on the latest 1.81 just for a small improvement like Duration::abs_diff() in 1.81.
Compare that with C++, Python, and other venerable languages where the only reasonable version to use is the one shipped by your distro, which can take months to handle the various regressions before pushing an update, and where it's common for your users to be years behind the latest compiler.
Being able to easily use the latest compiler and even experimental features is undeniably a good thing, even if part of the community raises their minimum required version a bit too aggressively.
Posted Oct 11, 2024 9:41 UTC (Fri)
by bfeeney (guest, #6855)
[Link] (3 responses)
I think you're conflating "Rust for Linux" and the "Rust language".
I think you're also being misled by the term "unstable".
Linux currently is built with a variety of non-standard GCC extensions that are not part of the C language specification. These come and go at any point, which is why the kernel tends to pin a particular GCC version.
Rust for Linux is in the exact same situation: it uses extensions that are not part of the format Rust language specification.
Unlike with GCC however, you cannot use extensions from a stable release of the compiler. You have to use one of the nightly releases. This is combination of non-standard feature and nightly compiler release is the meaning of the word "unstable" here.
However despite the "unstable" description, one should note that Rust uses the unstable-branch/stable-trunk philosophy, and has an extensive test suite employed for every "nightly release" which it must pass in order to be made available.
The only difference between C/GCC and Rust/Rustc is there is a plan to formally incorporate the extensions for Rust for Linux into the Rust language specification in the short term, which does not exist for C/GCC.
The Rust compiler and language are stable, in the sense that they're bug free.
Posted Oct 11, 2024 11:48 UTC (Fri)
by pizza (subscriber, #46)
[Link] (2 responses)
Got a citation for the "and go at any point" ?
GCC has historically been _very_ consistent with intentional behavior, and has a very long timeline for the deprecation and removal of features.
Meanwhile, with regards to "pinning" GCC versions, (when I checked a few weeks ago) the minimum required version to compile Linux is v5.1 [1], released over 9 years ago, and the system I'm typing this on uses the latest GCC release (14.2). Regressions do happen of course, but GCC and Kernel developers are quite diligent about fixing those when they occur..
[1] Granted, you may need a newer version than that if you have a more recent CPU architecture, or turn on an optional feature (eg one of the many hardening plugins) that needs a newer GCC version.
Posted Oct 11, 2024 12:20 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (1 responses)
Like VLAs?
Posted Oct 11, 2024 12:45 UTC (Fri)
by pizza (subscriber, #46)
[Link]
I asked for an actual citation, not a TLA.
...The only reference I can find about VLAs was when they were formally _documented_ as a GCC extension to C++ (as opposed to just an extension to C since appoximately forever). I found nothing about support for VLAs being _removed_.
Meanwhile, VLAs are actually part of the C99 spec and documented as supported in the latest GCC 14 releases.
So... again, [citation needed] about "and go at any point".
But why
But why
But why
But why
But why
But why
But why
But why
But why
But why
But why
But why
But why
But why
But why
But why
(It's been what, over two decades since I last remember pinning an old GCC version for kernel use?)
But why
But why