3 ms·

> 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 multip

> 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...

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...