3 ms·

> but it only has 40 dependents Isn’t sha1 a several hundred line function? What’s going on?

by liontwist 2y ago

the_mitsuhiko 2y ago
In case I was unclear it has 0 dependencies, but 40 crates in the ecosystem depend on it.
- liontwist 2y ago
  My mistake.
gpm 2y ago
The rust-crypto sha1 crate has four direct dependencies cfg-if - a tiny library making it easier to use different implementations on different platforms. Maintained by the official rust-lang libs team. Also used by the rust std library. No recursive dependencies. cpufeatures - a tiny library for detecting CPU features maintained by the rust-crypto people, with a recursive dependency only on libc (which is maintained by rust-lang and used by the standard library). digest - a library providing traits abstracting over different hash functions, maintained by the rust-crypto-people. In turn digest depends blockbuffer (some code to minimize boundchecks) and cryptocommon (more traits for abstracting), both maintained by the rust-crypto people. Both in turn depend on - typenum, a third party library for compile time math, no dependencies. - generic-array, a third library for fixed length arrays with lengths computed by typenum, typenum is its only dependency. - version_check, a third party library for checking what features the rustc being used supports (only block-buffer depends on this one). sha1-asm - A library with a faster assembly implementation of sha1, maintained by the rust-crypto people. Dependent only on cc (c compiler support), maintained by rust-lang, used in building the rust compiler. cc is itself in turn dependent only on - shlex, a third party library for splitting things the same way a shell does. So this tree ends in an actual third party dependency, but one you're already indirectly dependent on by simply using the rust compiler at all. Oh, and in the next release sha1-asm is being removed The crypto common dependencies are being replaced with hybrid-array, which is a replacement for generic-array maintained by the rust-crypto people, and is only dependent on typenum. The version_check dependency is being dropped. --- So what's going on is 1. This is a faster implementation of sha1, using all the tricks to have different implementations on different platforms. This resulted in 2 third party dependencies, down to 1 in the next release. 2. This is fitting into a trait ecosystem, and is using tricks to abstract over them without degrading performance. This resulted in 2 third party dependencies, down to 1 in the next release. 3. The count of non-third party dependencies is inflated because rust-crypto has split up its code into multiple crates, and the rust-lang team has split its code up into multiple crates. 4. It's not 40, it's 9. Is it worth the extra code? I guess that depends on how many times you are hashing things and how much you care about the performance and environmental impact of extra code. Or if you're doing something where you want to be generic over hash functions.
- Izkata 2y ago
  > 4. It's not 40, it's 9. Just like a bunch of others, you understood their comment backwards. Dependents, not dependencies. 40 other things rely on it.
  - gpm 2y ago
    Uh, no, I understand the comment I was replying to forwards. I simply decided not to point out the source of their misunderstanding since it had already been pointed out by the time I replied, and this comment is already way too long.

> but it only has 40 dependents Isn’t sha1 a several hundred line function? What’s going on?

the_mitsuhiko 2y ago

In case I was unclear it has 0 dependencies, but 40 crates in the ecosystem depend on it.

liontwist 2y ago
My mistake.

gpm 2y ago

The rust-crypto sha1 crate has four direct dependencies cfg-if - a tiny library making it easier to use different implementations on different platforms. Maintained by the official rust-lang libs team. Also used by the rust std library. No recursive dependencies. cpufeatures - a tiny library for detecting CPU features maintained by the rust-crypto people, with a recursive dependency only on libc (which is maintained by rust-lang and used by the standard library). digest - a library providing traits abstracting over different hash functions, maintained by the rust-crypto-people. In turn digest depends blockbuffer (some code to minimize boundchecks) and cryptocommon (more traits for abstracting), both maintained by the rust-crypto people. Both in turn depend on - typenum, a third party library for compile time math, no dependencies. - generic-array, a third library for fixed length arrays with lengths computed by typenum, typenum is its only dependency. - version_check, a third party library for checking what features the rustc being used supports (only block-buffer depends on this one). sha1-asm - A library with a faster assembly implementation of sha1, maintained by the rust-crypto people. Dependent only on cc (c compiler support), maintained by rust-lang, used in building the rust compiler. cc is itself in turn dependent only on - shlex, a third party library for splitting things the same way a shell does. So this tree ends in an actual third party dependency, but one you're already indirectly dependent on by simply using the rust compiler at all. Oh, and in the next release sha1-asm is being removed The crypto common dependencies are being replaced with hybrid-array, which is a replacement for generic-array maintained by the rust-crypto people, and is only dependent on typenum. The version_check dependency is being dropped. --- So what's going on is 1. This is a faster implementation of sha1, using all the tricks to have different implementations on different platforms. This resulted in 2 third party dependencies, down to 1 in the next release. 2. This is fitting into a trait ecosystem, and is using tricks to abstract over them without degrading performance. This resulted in 2 third party dependencies, down to 1 in the next release. 3. The count of non-third party dependencies is inflated because rust-crypto has split up its code into multiple crates, and the rust-lang team has split its code up into multiple crates. 4. It's not 40, it's 9. Is it worth the extra code? I guess that depends on how many times you are hashing things and how much you care about the performance and environmental impact of extra code. Or if you're doing something where you want to be generic over hash functions.

Izkata 2y ago
> 4. It's not 40, it's 9. Just like a bunch of others, you understood their comment backwards. Dependents, not dependencies. 40 other things rely on it.
- gpm 2y ago
  Uh, no, I understand the comment I was replying to forwards. I simply decided not to point out the source of their misunderstanding since it had already been pointed out by the time I replied, and this comment is already way too long.