Thoughts and clarifications
Thoughts and clarifications
Posted Sep 4, 2024 18:13 UTC (Wed) by Deleted user 129183 (guest, #129183)In reply to: Thoughts and clarifications by wtarreau
Parent article: Whither the Apple AGX graphics driver?
This observation is very on point, since this is what has recently *actually* happened in relation to the ’Rust for Linux’ project. If anyone does not remember:
https://lwn.net/Articles/987635/
Even the time frame is largely accurate, lol.
Posted Sep 4, 2024 18:25 UTC (Wed)
by daroc (editor, #160859)
[Link] (19 responses)
Posted Sep 4, 2024 18:45 UTC (Wed)
by Deleted user 129183 (guest, #129183)
[Link] (18 responses)
So far. But reading such articles like the one above, I think that more people will likewise resign in the near future. Especially since it seems that the Rust culture (that likes to ‘move fast and break things’) is a poor match for the Linux culture (where even the very important changes can take more than two years to be done).
Posted Sep 4, 2024 18:48 UTC (Wed)
by corbet (editor, #1)
[Link] (12 responses)
Posted Sep 4, 2024 19:45 UTC (Wed)
by khim (subscriber, #9252)
[Link] (10 responses)
Technically Rust culture is releasing new, incompatible, versions of crates very often. That's what C++ folks call “move fast and break things”, but compared to Linux development that's actually “move slow”, because breaking changes in Rust crates are still coordinated and pre-announced, while Linux-internal APIs sometimes are broken without warnings and it's not even possible to use code that is designed against old API while in Rust linking in two incompatible versions of crates into one binary is allowed and supported case. Rust developers are often liking to use latest version of Rust compiler, while Linux kernel is extremely conservative in regard to use of new features of gcc or clang, but that's much less pressing concern: kernel is known to to include optional features that even require use of pre-release versions of gcc or clang if they are worth it.
Posted Sep 4, 2024 19:58 UTC (Wed)
by mb (subscriber, #50428)
[Link] (8 responses)
Well, you could not be more wrong than that.
Crate maintainers almost all care deeply about compatibility and use Semver to express that.
Yes, there are some crates that update and break often. But saying that this is "the Rust culture" is just plain wrong and shows more about your experience with the Rust community than the Rust community itself.
This is all the complete opposite of the C/C++ universe, where a commonly agreed versioning scheme does not exist, everybody does versioning differently.
Posted Sep 4, 2024 20:29 UTC (Wed)
by khim (subscriber, #9252)
[Link] (7 responses)
Seriously? Even rand, a very narrow crate that you first encounter in a Rust Book have 9 versions. Clap (that you find in many other tutorials) have 13 versions, ndarray have 16 and so on. That's quite a lot, compared to many other languages where you may find 3-4 versions released over decade instead of 10-15, and where every release is “a big deal”™. Sure, but that doesn't change the fact that changes are breaking and support for old version is, often, immediately dropped when new version is released. As I have said: it's still better than how in-kernel APIs are treated, but that's unusual from POV of Java or even C++ developers. Can you show me any Rust apps that doesn't rely on these crates that have dozen releases or more? True, but how many C++ libraries that have more than dozen incompatible releases can you name? They exist, sure, but how common they are? Qt had fewer incompatible releases in ⅓ century than
Posted Sep 4, 2024 21:18 UTC (Wed)
by mb (subscriber, #50428)
[Link] (6 responses)
The latest version 0.8.x is supported and compatible since more than three years.
>Clap (that you find in many other tutorials) have 13 versions,
version 4 is compatible since two years.
>That's quite a lot
No, it's not. The criteria for bumping the major are completely different compared to almost all major C libraries.
>where every release is “a big deal”™.
It's not.
>Sure, but that doesn't change the fact that changes are breaking and support for old version is, often, immediately dropped when new version is released.
So? That's exactly the same for basically every Open Source software out there.
And nobody stops you from supporting your favorite old "rand".
You are asking for long term support that you get nowhere else.
>Can you show me any Rust apps that doesn't rely on these crates that have dozen releases or more?
The times any build broke in the whole time I used Rust is in the low single digits. I think it's two or three times.
>Qt had fewer incompatible releases in ⅓ century than rand in 10 years!
Oh. So you also don't have any experience with Qt major upgrades.
Great. Let me explain it to you: Most of the major Qt version bumps require massive changes in the project.
The number of major versions does not mean anything, if you accumulate the changes until an extremely loud big bang release.
Posted Sep 4, 2024 22:26 UTC (Wed)
by khim (subscriber, #9252)
[Link]
That's different question, though. It's question of whether “move fast and break things” approach is better than alternatives. While similar C++ facility had no breaking changes ever. But was extended few times. I had it going for ten years with Python2, Java8 and many other tools, sorry. Sure, but that, again, discusses virtues of “move fast and break things” approach versus “keep it stable as long as you can, then do a massive break when you can not anymore” approach. I think nowadays “move fast and break things” approach becomes more and more popular (and as I have pointed out and you repeated that's how kernel manages internal APIs, too). But that doesn't change the fact that it's different approach from what many other languages, especially “enterprise” ones, practise (or practised). Lots of projects, these days, go overboard with “move fast and break things”, though. At least temporarily. Although they eventually change their approach AFAICS: even flagship of that approach, Abseil, these days offers more Rust-like approach with compatible releases every half-year or so. They proudly proclaim them LTS, which, of course, sounds ridiculous since they are only supported for one year, but still… it's closer to what Rust does then to either “everyone should just live on
Posted Sep 5, 2024 3:08 UTC (Thu)
by legoktm (subscriber, #111994)
[Link] (1 responses)
I'd also say that people care a lot about good API design, and as a result iterate (with breaking changes) until they reach 1.0 and then intend to keep it stable forever like serde. If I had to complain about something it's probably that people are, in my opinion, too perfectionist, and don't declare the 1.0 despite their crate being stable. (Of course, I'm also guilty of this in my own crates.)
Posted Sep 5, 2024 7:11 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Indeed, lots of very basic crates are stuck forever at This may be, very well, their intent (and in some rare cases, like with Rust compiler itself, even actual accoplishment), but that's not what developer have to deal with. In the absence of that mythical And cargo-semver-checks is certainly not unique, that's Rust version of abidiff, essentially. And it maybe even true that radical and drastic breakages every dozen of years may be harder to deal with than regular and frequent yet minor breakages, but that doesn't change the fundamental approach to how Rust community operates: while many developers dream of replicating the Rust compiler feat of breaking things and moving fast in the beginning while reaching eventual stability, after which development still advances but at glacial speed, but often they only manage to achieve the first part. That's still more honest and better than many C libraries that proclaim to release compatible versions which in reality break programs, but one couldn't claim your are not breaking things if you routinely release new, incompatible, versions while simultaneously stop supporting old versions.
Posted Sep 5, 2024 10:01 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
I maintain a few Qt projects. Since when are massive changes needed to bump? That is not my experience at all.
Posted Sep 5, 2024 10:09 UTC (Thu)
by mb (subscriber, #50428)
[Link] (1 responses)
2 to 3, 3 to 4 and 5 to 6 were pretty massive changes in my projects.
Posted Sep 8, 2024 8:53 UTC (Sun)
by chris_se (subscriber, #99706)
[Link]
Posted Sep 22, 2024 17:46 UTC (Sun)
by Rudd-O (guest, #61155)
[Link]
If you are a Rust programmer, you are not forced to upgrade to the latest and greatest crate. You could just keep using the old crate, it's still published, you can still download it, and unless you have security issue, there's no issue for you. You can even use multiple versions of the same crate in the same project, and it just works. This is the opposite of move fast and break things. It is rather move fast, keep old things working the way they were.
Moreover, kernel developers don't gratuitously use crates like your comment would seem to imply. The vast majority of crates are simply unusable in the kernel because they depend on the standard library. And the standard library cannot be linked into the kernel because the standard library has some requirements regarding memory allocation that cannot be fulfilled by the kernel.
I find it absolutely amazing that you can add a few YAML lines to your GitHub project and there's an entire computer network that will automatically upgrade all of your crates in your Rust project that's on GitHub. And then subsequently your CI fires and everything is tested so that you know all the upgrade didn't break anything. I used that all the time. But this is absolutely unrepresentative of how kernel development with Rust code is done. Maybe someday that will be the case. Maybe in 25 years. We're not even close to that. We need to get even a few crates going in the kernel before that's even a concern in anyone's radar.
If anything, Rust in the kernel is actually move slow. And if we are to conclude anything from the rust for Linux developers' contributions to the Linux kernel, it has been move slow and fix other people's things.
Posted Sep 4, 2024 19:48 UTC (Wed)
by corbet (editor, #1)
[Link]
Posted Sep 5, 2024 0:51 UTC (Thu)
by Ashton (guest, #158330)
[Link]
The most recent drama was about some C developers asserting that they will break things and not even inform the rust developers.
Posted Sep 5, 2024 10:56 UTC (Thu)
by agateau (subscriber, #57569)
[Link] (1 responses)
There is a difference between A) breaking things unannounced and B) breaking things by bumping the major version of your project.
In my experience it's much more common in the Rust ecosystem to go with B than with A. And B is usually not a problem in that dependent projects are unlikely to hit unexpected build breakages. My experience in other ecosystems is very different...
Posted Sep 5, 2024 12:13 UTC (Thu)
by Ashton (guest, #158330)
[Link]
In the abstract if someone asserted that a major, risk sensitive project in a language took a much more conservative approach to dependencies and change than the average user of the same language I would be utterly unsurprised.
Posted Sep 5, 2024 19:38 UTC (Thu)
by MarcB (guest, #101804)
[Link]
Where is this coming from?! "Moving fast and breaking things" is basically the least fitting description of "Rust culture" (whatever that may be).
Posted Sep 22, 2024 17:41 UTC (Sun)
by Rudd-O (guest, #61155)
[Link]
🤣 where would anyone get that opinion from? Honest question!
Thoughts and clarifications
Thoughts and clarifications
The Rust folks have neither moved fast nor broken things. This kind of comment is not helpful.
Thoughts and clarifications
Thoughts and clarifications
Thoughts and clarifications
The opposite of what you say is true.
Breaking changes are not frequent in most crates and if breaking Semvers are released, it's often trivial to upgrade. Breaking changes are not frequently done for most crates.
The kernel is a prime example of not having a stable internal API and breaking things all the time.
> The opposite of what you say is true.
Thoughts and clarifications
rand in 10 years! And if you compare size of API that Qt offers to what rand offers… difference is even more stricking.Thoughts and clarifications
Even extremely small theoretical breakages cause a major bump.
There are only very few projects providing long term support of old versions.
Updates are extremely smooth.
Whereas most of the crate major version bumps just work with little to no change.
It can even be argued that a big release every 5 years is worse than small incremental changes every year.
> It can even be argued that a big release every 5 years is worse than small incremental changes every year.
Thoughts and clarifications
Whereas most of the crate major version bumps just work with little to no change.
HEAD” or “breaking changes should happen once per half-century” extremes.Thoughts and clarifications
> If I had to complain about something it's probably that people are, in my opinion, too perfectionist, and don't declare the 1.0 despite their crate being stable.
Thoughts and clarifications
version zero, even such basic crates as libcversion 1.0 crate people are forced to use what they have available. And what they have available is, very often, not that bad! For all practical purposes, in a Rust world, version 1.0 is just a number: if crate is version zero crate then minor number work like major number for crates after version 1.0. And it's not as if breaks stops after version 1.0: syn is at version 2.0, clap is at version version 4.5, etc.Thoughts and clarifications
Thoughts and clarifications
That only leaves 4 to 5 as a small upgrade with small changes for me.
Qt major version upgrades
Thoughts and clarifications
I should clarify that I was talking about the behavior of the Rust developers in the kernel project. I'm taking no position on all proponents of any language.
Thoughts and clarifications
Thoughts and clarifications
Thoughts and clarifications
Thoughts and clarifications
Thoughts and clarifications
Thoughts and clarifications