2 ms·

For 1), Cargo already take care of that if you use the same major version. Bundling dependencies in the stdlib "solves" the problem by making new major versions

For 1), Cargo already take care of that if you use the same major version. Bundling dependencies in the stdlib "solves" the problem by making new major versions impossible. This means that if a bundled dependency in the stdlib is even found to have some design issue that require breaking changes to fix then you're out of luck. As you said the stdlib could deprecate the old version and add a new one, but then you're just making problem 2) worse by forcing everyone to include the old deprecated dependency too! Or you could use a third-party implementation, especially if the stdlib doesn't have the features you need, but even then you will still be including the stdlib version in your dependency graph! Ultimately IMO bundling dependencies in the stdlib just makes the problem worse over time, though it can raise awareness about how to better handle them.

DanielHB 2y ago
> Cargo already take care of that if you use the same major version. Most dependency management systems do that, but large projects often end up pulling multiple different major versions of (often very large) dependencies. > 2) worse by forcing everyone to include the old deprecated dependency too! Like I said I am no expert on Rust, but I assume that Rust can eliminate stdlib dead-code from the runtime? So unused deprecated features shouldn't be included on every build? Also deprecated features often are modified to use the new implementation under the hood which reduces code duplication problem. > Bundling dependencies in the stdlib "solves" the problem by making new major versions impossible. Yes, which is a feature. For example Go is very annoying about this not only on the stdlib. https://go.dev/doc/go1compat https://go.dev/doc/go1compat a lot of 3rd party libs follow this principle as well. I bring Go a lot but I actually don't like the language that much, but it gets some pragmatic things right. I am not saying everything should be in the stdlib, but I tend to think that the stdlib should be fairly big and tackle most common problems.
- SkiFire13 2y ago
  > > Bundling dependencies in the stdlib "solves" the problem by making new major versions impossible. > > Yes, which is a feature. For example Go is very annoying about this not only on the stdlib. https://go.dev/doc/go1compat https://go.dev/doc/go1compat a lot of 3rd party libs follow this principle as well. But there's no reason such a "feature" requires bundling dependencies in the stdlib. As you mention 3rd party Go libs manage to do this perfectly fine. > but I tend to think that the stdlib should be fairly big and tackle most common problems. I tend to disagree with this, because the way to tackle those common problems with likely change in the future, but the stdlib will be stuck with it for eternity. I would rather have some community-standard 3rd party crate that you can replace in the future when it will grow old. See also "Where modules go to die" https://leancrew.com/all-this/2012/04/where-modules-go-to-die/ https://leancrew.com/all-this/2012/04/where-modules-go-to-di...

DanielHB 2y ago

> Cargo already take care of that if you use the same major version. Most dependency management systems do that, but large projects often end up pulling multiple different major versions of (often very large) dependencies. > 2) worse by forcing everyone to include the old deprecated dependency too! Like I said I am no expert on Rust, but I assume that Rust can eliminate stdlib dead-code from the runtime? So unused deprecated features shouldn't be included on every build? Also deprecated features often are modified to use the new implementation under the hood which reduces code duplication problem. > Bundling dependencies in the stdlib "solves" the problem by making new major versions impossible. Yes, which is a feature. For example Go is very annoying about this not only on the stdlib. https://go.dev/doc/go1compat https://go.dev/doc/go1compat a lot of 3rd party libs follow this principle as well. I bring Go a lot but I actually don't like the language that much, but it gets some pragmatic things right. I am not saying everything should be in the stdlib, but I tend to think that the stdlib should be fairly big and tackle most common problems.

SkiFire13 2y ago
> > Bundling dependencies in the stdlib "solves" the problem by making new major versions impossible. > > Yes, which is a feature. For example Go is very annoying about this not only on the stdlib. https://go.dev/doc/go1compat https://go.dev/doc/go1compat a lot of 3rd party libs follow this principle as well. But there's no reason such a "feature" requires bundling dependencies in the stdlib. As you mention 3rd party Go libs manage to do this perfectly fine. > but I tend to think that the stdlib should be fairly big and tackle most common problems. I tend to disagree with this, because the way to tackle those common problems with likely change in the future, but the stdlib will be stuck with it for eternity. I would rather have some community-standard 3rd party crate that you can replace in the future when it will grow old. See also "Where modules go to die" https://leancrew.com/all-this/2012/04/where-modules-go-to-die/ https://leancrew.com/all-this/2012/04/where-modules-go-to-di...