Thoughts and clarifications
Thoughts and clarifications
Posted Sep 4, 2024 19:58 UTC (Wed) by mb (subscriber, #50428)In reply to: Thoughts and clarifications by khim
Parent article: Whither the Apple AGX graphics driver?
Well, you could not be more wrong than that.
The opposite of what you say is true.
Crate maintainers almost all care deeply about compatibility and use Semver to express that.
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.
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.
The kernel is a prime example of not having a stable internal API and breaking things all the time.
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]
> 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