This is exactly why I wouldn't use Rust for any project that has to be maintained long-term.
Virtually any application requires a lot of 3rd party dependencies, even for very basic stuff such as error handling.
But the state of the ecosystem is crap. Crates have breaking changes all the time, when they're not abandoned. Plus they have incompatible interfaces, require different Rust versions, etc.
A working composition remains very fragile. Updating a dependency or introducing a new one may break everything.
Rust requires a lot of maintenance. This is expensive, and, for open source projects, not fun at all.
I abandoned projects, and keep using old crate version on others (something even with vulnerabilities), because keeping all these things up to date is too much work, not productive. I don't want to spend time making things that work still work.
Contrast to Go and Zig that have a rich standard library, where the number of required 3rd party dependencies can be kept down to a minimum.
Go also has a culture of stability. I generally just update all the dependencies, and everything works. Been doing that for years for some projects, and incompatibilities have been extremely uncommon.
Rust has the opposite culture. It looks like a never-ending quest to do things "right", and breaking APIs is common practice.
The article highlights the fact that many crates on crates.io don't match their source code. But even more alarming is the number of projects depending on crates or crate versions that have been abandoned.
There's also probably the fad factor. People discover Rust, are as excited as one can be when discovering a new thing, work on a few things to learn the language, make shameless self-promotion on hacker news, and eventually get bored and move on. So we get tons of software and crates that get abandoned.
This applies to all programming languages, but Rust seems to be especially affected.
And this is an issue to other developers when this affects dependencies. As a workaround, I tend to reimplement these crates or write wrappers. Which is also a waste of time and produces more fragmentation.
So yeah, the solution would be a better standard library. But this is a ton of work, and I would argue that it is too late.
Virtually any application requires a lot of 3rd party dependencies, even for very basic stuff such as error handling.
But the state of the ecosystem is crap. Crates have breaking changes all the time, when they're not abandoned. Plus they have incompatible interfaces, require different Rust versions, etc.
A working composition remains very fragile. Updating a dependency or introducing a new one may break everything.
Rust requires a lot of maintenance. This is expensive, and, for open source projects, not fun at all.
I abandoned projects, and keep using old crate version on others (something even with vulnerabilities), because keeping all these things up to date is too much work, not productive. I don't want to spend time making things that work still work.
Contrast to Go and Zig that have a rich standard library, where the number of required 3rd party dependencies can be kept down to a minimum.
Go also has a culture of stability. I generally just update all the dependencies, and everything works. Been doing that for years for some projects, and incompatibilities have been extremely uncommon.
Rust has the opposite culture. It looks like a never-ending quest to do things "right", and breaking APIs is common practice.
The article highlights the fact that many crates on crates.io don't match their source code. But even more alarming is the number of projects depending on crates or crate versions that have been abandoned.
There's also probably the fad factor. People discover Rust, are as excited as one can be when discovering a new thing, work on a few things to learn the language, make shameless self-promotion on hacker news, and eventually get bored and move on. So we get tons of software and crates that get abandoned. This applies to all programming languages, but Rust seems to be especially affected.
And this is an issue to other developers when this affects dependencies. As a workaround, I tend to reimplement these crates or write wrappers. Which is also a waste of time and produces more fragmentation.
So yeah, the solution would be a better standard library. But this is a ton of work, and I would argue that it is too late.