5 ms·

> If OP is willing to maintain a rust crate that takes in no dependencies and can determine terminal size on any platform I choose to build for, then I will gla

> If OP is willing to maintain a rust crate that takes in no dependencies and can determine terminal size on any platform I choose to build for, then I will gladly use your crate. I already mentioned this on twitter but not a lot of people work this way. I don't have to point you farther than my sha1-smol crate. It was originally published under the sha1 name and was the one that the entire ecosystem used. As rust-crypto became more popular there were demands that the name was used for rust-crypto instead. I have given up the name, moved the crate to sha1-smol. It has decent downloads, but it only has 40 dependents vs. >600 for sha1. Data would indicate that people don't really care all that much about it. (Or the sha1 crate is that much better than sha1-smol, but I'm not sure if people actually end up noticing the minor performance improvements in practice)

jvanderbot 2y ago
Ha! Hi, I think we're having parallel conversations on there as well. Well, good to make a second loop closure. I won't copy my reply here.
liontwist 2y ago
> 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.
andyferris 2y ago
Not trying to be perverse - but why does sha1-smol need any dependencies, let alone 40? Isn’t it a single public pure function from a slice of bytes to a u128? (Implemented with some temporary state and a handful of private functions.) (I am likely being completely naive, but I am well satisfied by Julia’s stdlib function for this, so wondering what makes Rust different since I’ve been doing more and more rust lately and am trying to understand what the difference might be).
- the_mitsuhiko 2y ago
  > Not trying to be perverse - but why does sha1-smol need any dependencies, let alone 40? It has zero dependencies, but only 40 crates on the eco system depend on it. Compared to sha1 which has 10 dependencies, but > 660 crates depend on it.
  - andyferris 2y ago
    Oh right! Gotcha, I had it backwards.
WhyNotHugo 2y ago
Do you still stand by your decision to give over the `sha1` name?
- the_mitsuhiko 2y ago
  I don't care that much about the name. It was already clear that even ignoring the name, that the rust-crypto ecosystem became the mainstream choice.

jvanderbot 2y ago

Ha! Hi, I think we're having parallel conversations on there as well. Well, good to make a second loop closure. I won't copy my reply here.

liontwist 2y ago

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

andyferris 2y ago

Not trying to be perverse - but why does sha1-smol need any dependencies, let alone 40? Isn’t it a single public pure function from a slice of bytes to a u128? (Implemented with some temporary state and a handful of private functions.) (I am likely being completely naive, but I am well satisfied by Julia’s stdlib function for this, so wondering what makes Rust different since I’ve been doing more and more rust lately and am trying to understand what the difference might be).

the_mitsuhiko 2y ago
> Not trying to be perverse - but why does sha1-smol need any dependencies, let alone 40? It has zero dependencies, but only 40 crates on the eco system depend on it. Compared to sha1 which has 10 dependencies, but > 660 crates depend on it.
- andyferris 2y ago
  Oh right! Gotcha, I had it backwards.

WhyNotHugo 2y ago

Do you still stand by your decision to give over the `sha1` name?

the_mitsuhiko 2y ago
I don't care that much about the name. It was already clear that even ignoring the name, that the rust-crypto ecosystem became the mainstream choice.