Comment by iLemming
2 days 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.
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.
> No, many are truly abandoned.
I've complained about that in the 3D graphics area. But that's niche. Recently I had to write some webcrap, a web server responder that runs under Apache mod_fcgid. I expected that area to Just Work. Works fine in Go, out of the box. There were about a half-dozen abandoned crates which sort of implemented that kind of server. I had to write one from scratch.[1]
The Rust compiler is great, but the crates... There are now enough of them to need curation. Some need to be moved to some obsolete status. Some need to make it to 1.0. Crates.io is starting to clog up with junk.
[1] https://github.com/John-Nagle/maptools/blob/main/server/src/...
I believe https://lib.rs/ aims to present information to find better crates.
I don't mind sorting by downloads or recent updates, so not all is loat, but I wish the status pages (are we X) and guides kept up.
Do you have examples
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.
> 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.
There is nothing like "done" here. Somebody has to update dependencies at least - for security reasons.
> I see it too often e.g., in Clojure, where lib authors even have to add "maintenance disclaimers"
I think this is a peculiarity of Clojure. Clojure is optimized for simplicity and as the saying goes: "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."
I don't use Clojure these days. Maybe I should revisit the language. It has some really nice ideas.