undefined | Better HN

0 pointsSkiFire131y ago0 comments

> try to support minimum-dependency projects by having a broad std library.

Since everyone depends on the standard library this will just mean everyone will depend on even more lines of code. You are decreasing the number of nominal dependencies but increasing of much code those amount to.

Moreover the moment the stdlib's bundled dependency is not enough there are two problems:

- it can't be changed because that would be a breaking change, so you're stuck with the old bad implementation;

- you will have to use an alternative implementation in another crate, so now you're back at the starting situation except with another dependency bundled in the stdlib.

Just look at the dependency situation with the python stdlib, e.g. how many versions of urllib there are.

0 comments

DanielHB1y ago

You do have good points as well and it depends heavily on how disciplined the std lib makers are. Go for example has a very clean and stable std lib.

I posted this in some other thread:

I am not a Rust expert but the thing with the standard libraries is that it only has peer dependencies with itself and they are all synced to the same version. Meaning if you only use the std lib you:

1) Will never include two different versions of the same peer dependency because of incompatible version requirements.

2) Will usually not have two dependencies relying on two different peer-dependencies that do the same thing. This can still happen for deprecated std lib features, but tends to be a much lesser issue.

These two issues are usually the ones that cause dependency size explosion in projects.

SkiFire13OP1y ago

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.

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

1 more reply

norman7841y ago

I would argue that Go is focused on writing web services and their stdlib is focused on providing those primitives. On the other hand Rust is more general programming language, so it's harder to add something to the stdlib that would not benefit the broader range of users.

j / k navigate · click thread line to collapse

0 pointsSkiFire131y ago0 comments

> try to support minimum-dependency projects by having a broad std library.

Moreover the moment the stdlib's bundled dependency is not enough there are two problems:

- it can't be changed because that would be a breaking change, so you're stuck with the old bad implementation;

- you will have to use an alternative implementation in another crate, so now you're back at the starting situation except with another dependency bundled in the stdlib.

Just look at the dependency situation with the python stdlib, e.g. how many versions of urllib there are.

0 comments

DanielHB1y ago

You do have good points as well and it depends heavily on how disciplined the std lib makers are. Go for example has a very clean and stable std lib.

I posted this in some other thread:

1) Will never include two different versions of the same peer dependency because of incompatible version requirements.

These two issues are usually the ones that cause dependency size explosion in projects.

SkiFire13OP1y ago

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.

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.

DanielHB1y 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!

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

1 more reply

norman7841y ago

j / k navigate · click thread line to collapse