| The dependency thing worries me to a fair degree. Amazon has (or at least had when I was there) a build tool fairly similar to cargo. Libraries and software was imported in to the underlying repositories with a version associated. You put that in your list of dependencies and voila when you built your code everything got neatly combined and compiled as needed. One routine source of pain was when one of your upstream dependencies changed its dependencies. That would happen quite routinely. All was fine, unless you actually had two packages that had dependencies on different versions of a library. You could work around it by pinning the version of the dependency, but of course that's risky. You don't know if you're exposing yourself to bugs, because you're making software run with a dependency version it hasn't been tested against. Pretty much every build file I ever saw in Amazon had at least a half dozen or more dependencies pinned. Every now and then you'd find you were getting a new dependency conflict, and that things had become an impossible knot to untangle. All you could do is unpin _everything_ and then figure out all the version pins you needed again from scratch. I swear I would lose at least one to two days a quarter doing that. The development focussed teams would spend way more than that on fixing conflicts. I started out with Rust just last weekend. Put a couple of dependencies in the Cargo.toml library and got stunned when it pulled in over 400 dependencies, a number of which I'd expect to have seen in the stdlib, not left to the vagaries of random people's implementations. |
And it has a lockfile, so your dependencies won't update if you don't want them to.
The only problem is C dependencies like OpenSSL that do break their API, and don't support multiple copies per executable, so there's nothing that Rust/Cargo can do about it (you as a user can avoid them and choose native Rust libs where possible).