IME unmaintained Rust packages usually aren't an issue, because Rust's backwards-compatibility is really good. Only if there's an unidiomatic design or bug in the part that you use, or a security vulnerability.

Rust dependency bloat may be an issue, but with good static analysis maybe not (the compiler can effectively remove dead code unlike JavaScript, and the IDE may be able to effectively filter it).

That's the main criticism my colleagues have about Rust: a lot of unmaintained crates, and most of the time a lot of dependencies for... (almost) nothing.

It seems most of Rust developers adopt the pov of web front-end developers since a few years: depend on a lot of libraries for small things, never update your project to 1.0, and abandon "quickly" to build something new... and redo it again.

I really hope that alternatives like Zig or Jai will not let the community do like what they did with Rust.

Probably hard to do during nine-to-five, but personally commit to being a contributor on every dependency used.

Like having mini contracts with every package, even if it's just to reproduce bugs, maintain a personal test suite, or to steer newcomers to resources.

Otherwise, we will always be in the dark about our dependencies, building our flying castles. (They float, but where's the foundation?)

Alternatively, there are open-source code scanners and bill-of-material security tools. Those could be added as triggered workflows in your projects, to run on each pull request.

As well, the author did rewrite dotenv's core features to replace it.

> Many call for adding more to the rust standard library much like Go

> So now I pose the question to you what do we do?

1. Port your application to the language/tool that fits your needs like Go.

2. Hope that a language like Zig decides to feature a standard library as good as Go.