amos“every rust project has a billion dependencies”
oh no they made code composable oh nooooooo should we call someone??
rust has a lot of problems, but let me tell you: “micro libraries” isn’t one
splitting packages per concern is good for build performance, it’s good for review, it’s good for API evolution.
the problems are technical (compiler perf), financial (funding OSS), human etc.
mort@fasterthanlime When almost every one of those micro libraries are version 0.x however...
aoanla@mort @fasterthanlime Yeah, as others have noted, the issue with Rust (and Javascript) library dep explosion aren't the explosion itself, they're some of the causes (anemic standard library - Rust doesn't even have datetime!) and the specific contexts (every library is 0.1000.5 because no-one wants to stabilise at a release version, poor choices of repository system leading to "supply chain attacks" etc). Library explosions make this kind of thing hard to *identify*, which is bad.
@aoanla I wanna name another cause of the 0.x problem: there are plenty of packages out there, in version 0.x, which *have* a stable API and which have no trouble promising to keep their API stable. That's *why* they stick to 0.x: releasing 1.0 would break all their dependents, since 1.0 is incompatible with 0.x. If they're on 0.4.3, releasing 0.4.4 is safe: their users will get the new update; releasing 1.0 is risky: many of their users will stay on 0.4.3 because that's Cargo's default behavior
@mort Absolutely, but that's *clearly* short-termism - the pain of dropping a 1.0.0 wouldn't last, and the benefits - including *actually signaling correctly that your package is release-ready and stable* - would outweigh it quickly.
As it is, what they do is avoid pain but also perpetually *look* like they're never going to have a polished product/the package might go away at any time.
As it is, what they do is avoid pain but also perpetually *look* like they're never going to have a polished product/the package might go away at any time.