Comment by iLemming

Comment by iLemming 7 hours ago

I don't even write in Rust, yet I'm curious if those libraries you talk about are truly in "abandoned" state and not simply in "done" state? Some languages somehow managed to build thriving ecosystems of libraries where they don't require constant attention and perpetual churn like in JS and Python. I see it too often e.g., in Clojure, where lib authors even have to add "maintenance disclaimers" noting that the lib is good for what it was designed for and there are no plans to add new features and no known bugs or critical dependencies found, and the lib is not abandoned, and they update those notes periodically, just for the sake of showing any git activity.

jvanderbot 7 hours ago

No, many are truly abandoned.

I have this all the time. Any new rust project and you have to wade through a bunch of once-great crates.

But that's because rust is new. The initial surge over produced solutions to, say binary serialization, and under produced, say, good geodesy libraries. And many many were abandoned. Go to any of the "are we X yet" sites and you'll see many crates that are clearly not finished or advancing which were recently considered SoA.

Reply View 0 replies

fpoling 7 hours ago

Any library in Rust comes with Cargo.toml file listing dependencies and their versions. Rust build system allows to use later versions of the libraries so presumably an application that uses an old library will have dependencies for the library updated.

The problem is that sometimes library may need to pin a dependency version. Or a dependency was released with a newer major version update and do not back-port security fixes to older versions.

So one cannot just use an old library. Its dependency list must carefully considered.

Now this problem exists with any package management system. But in Rust it is more visible as the language still evolves quickly with non-trivial new features released often.

Then the library authors may want to use newer language features on their API. Then they simply bump the library mayor version and maintain only that. So an old dependencies will not get updates.

Reply View 1 reply

epage 4 hours ago

> The problem is that sometimes library may need to pin a dependency version.
We on the Cargo team have been working to educate people on the problems with pinning in Cargo.toml instead of relying on Cargo.lock
> Then the library authors may want to use newer language features on their API. Then they simply bump the library mayor version and maintain only that. So an old dependencies will not get updates.
Thankfully, the ecosystem has mostly settled on build requirements not being subject to SemVer and bump Rust versions in compatible releases. There are a few hold outs.

Reply View | 0 replies