Vetting the cargo [LWN.net]

Vetting the cargo

Posted Jun 14, 2022 22:18 UTC (Tue) by Wol (subscriber, #4433)
In reply to: Vetting the cargo by excors
Parent article: Vetting the cargo

It would be nice if the language writers had a "library of batteries" that is regularly maintained.

So you would have a "recommended battery for strings", "recommended battery for arbitrary precision maths", etc etc. And batteries could be maintained, deprecated, whatever. Especially as Rust has this version stuff, you could easily continue using old batteries, but - importantly - you would know they were old batteries and not actively maintained.

And if you want to deprecate and get rid of an old battery, provided the functionality has been updated, you could create your new battery and update the old battery to be - as far as possible - just a shim for the new one.

Cheers,
Wol

to post comments

Vetting the cargo

Posted Jun 15, 2022 8:49 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

> And if you want to deprecate and get rid of an old battery, provided the functionality has been updated, you could create your new battery and update the old battery to be - as far as possible - just a shim for the new one.

That's, actually, where you idea falls apart.

Maintaining compatibility is hard.

The deprecation of old crates and replacement with a new ones usually happen when the desired functionality is impossible to add in the backward-compatible way. Otherwise old crates are just extended.

Which more-or-less automatically makes these shims impractical: they would either be impossible or just simple larger and more error-prone than the whole old library.

That's why Linux kernel have “no stable internal API” policy and why Rust keeps it's standard library as small as possible.

As for “list of currently recommended crates”… this idea is discussed so often, that yes, I hope eventually something like that would be made. Maybe with the use of hyped cargo vet.

Vetting the cargo

Posted Jun 23, 2022 9:33 UTC (Thu) by Vipketsh (guest, #134480) [Link]

> Maintaining compatibility is hard.

Don't disagree here.

> The deprecation of old crates and replacement with a new ones usually happen when the desired functionality is impossible to add in the backward-compatible way.

In my experience statements to this effect are, for the most part, little more than mumbo-jumbo that people pushing for breakage use. The reality, again in my experience, is that backwards incompatible changes occur when some developer or group thereof decides that some new way of doing things looks more "pretty" than the current way so they make the change and then substantiate it with the above. I don't rule out that the average Rust developer is honest and hard working such that whenever faced with an issue they do their utmost to attempt to not break backward compatibility and my experience does not hold, but that is counter to everything I've seen thus I'm staying sceptical.

I would also like to point out the measure for "backwards-compatibility" has to be something like:
1, The overwhelming majority of your users don't notice
2, Those who do notice, notice small things and very rarely

Otherwise we end up with the absolutist argument of "every bug may be depended upon by someone, thus *any* change (no matter how straight-forward) may break something thus we wouldn't be able to change anything thus there is no backwards compatibility thus we can change everything willy-nilly".