It's not inherent to the language. It's inherent in the build tooling. Back in the cabal days haskell had the same problems. Nix is a more hermetic build and packaging tool which is why it's better at it.
Very curious to read about what it means to have a `hermetic build and packaging tool`.
In my naive view, there should be a way to at least cache the latest successful build from a package version. Then when users `cargo install ..`, it will check if a build was already made and retrieve it.
"at least cache the latest successful build from a package version"
Tools like guix and nix aim to describe packages in such a way that for the same input (package dependencies) you get the same output.
If the output is a function of the input, and you know a cached build of a package was built with the same input, then using the cached build of a package would be the same as if you'd built it yourself.
It does depend on whether the packages are written in a "pure" way. (Or "impure", such that building with the same inputs might result in different outputs).
https://github.com/NixOS/nix/issues/2270
I think that 'hermetic' here means that the build cannot depend on anything other than its input - it's built in a sealed environment where nothing other than the inputs is available. This property makes it more likely that the build products do indeed depend only on their explicit dependencies and not implicit dependencies.
The problem with caching just on package name and version is that there are many different possible flavours. For example, multiple different versions of the sourcecode may have the same given version number. Things such as target architecture, optimisation level, and optional features confuse things further. Nix therefore uses a hash of all the inputs as the cache key.
In my naive view, there should be a way to at least cache the latest successful build from a package version. Then when users `cargo install ..`, it will check if a build was already made and retrieve it.