Small nits about the way this works:

> By specifying the exact version you require,

This is only half true. It comes in two steps: you specify a _kind_ of version that you require, like

    foo = "^1.2.0"

and then, during the build step, it resolves all of the dependencies and their dependencies (etc) and writes the exact version out to a file. So you do end up with specific ones, but you won't neccesarily end up with multiple versions.

This also matters because...

> maintainers may neglect the tedious task of keeping their projects' dependencies up-to-date,

You just run 'cargo update' and it will re-calculate that dependency graph, and re-write out the lock file. You're as up to date as you can be. Of course, if that fix is only available in a range outside you've specified, that's different.

? As you may be aware, there is limited support for versioning APIs using "go get" (Go's nearest equivalent of this). The developers of Go argue that the maintenance of your dependencies is your responsibility, and you should clone everything you need to your own environment. That gives you ultimate control, allowing you to pull and update them as you require, modify and bugfix as you see fit, and makes it hard, if not impossible, to end up relying on two packages with different versions.

That's the last time where I heard about this wonderful idea that vendoring everything is a solution, because versioning is hard: https://www.kickstarter.com/projects/2066438441/haunts-the-m...

I'll take the solution where I can send a PR to the maintainer with updated dependencies over this sort of thing any day.

"The developers of Go argue that the maintenance of your dependencies is your responsibility" THIS!

I should also state I fall on the extreme end of the spectrum. My belief is that the moment you depend on upstream package X it is wholly your responsibility to track changes and adapt your code accordingly. I don't believe software versioning does anything but encourage poor security, performance and general fragmentation.

I believe that before pushing your changes to a remote repo, you locally check that everything is stable, meaning there is no dev branch or stable releases just one true master branch!

If you don't want the bleeding edge then don't 'git pull'. simple!

Cargo gives you exactly this, btw: if you don't want to change the version of upstream code on which you depend, don't run `cargo update`. (This applies to both git dependencies and registry dependencies.)

believe me I will 'cargo update' always! the problem is those who don't and still go on to publish libraries, what happens when he needs version 2.1 of X while another library needs version 3.4? And thus anyone who depends on these two libraries now ends up with duplicate libs. What if they also depend on other libs with the same problem...

The world goes boom! exponential overload!

... at least it get's really frustrating after a while, twice the space, twice the compilation time. And you'll know at least one of the libs has bugs lurking in it that have been fixed elsewhere except in that lib:(

Go is always statically linked at the moment so it makes more sense in that scenario.

I don't think that the linking semantics make much of a difference in what you should do with your source. Rust is, in fact, usually statically linked as well. Dynamically linked Rust crates are supported, but are uncommon in practice. (The most common use cases for dynamically linked Rust crates at the moment are compiler plugins and embedding Rust into other languages.)

For a dynamic library you need to ensure your source will work with the version range the package manager allows to be installed. Which may or may not be the most up to date version.

Subtle things in dynamic linking may break applications when dependency versions are changed.

Static linking lets you bundle whatever version is known to work, including the most up to date versions.