7 ms·

But also has a solution: https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev

by dpc_pw 7y ago

floor_ 7y ago
This is a solution to a problem that shouldn't have happened in the first place.
- swsieber 7y ago
  It's a naturally occurring phenomena when publishing packages is easy. There are various ways to address it: * Make it harder to publish * Make it easier to find quality packages I'd prefer the latter.
  - deleted 7y ago
    [deleted]
- dpc_pw 7y ago
  The alternatives are: * Have every single common thing live in a standard library which makes them stagnate, slows down language development and so on. * Have people roll their own half-baked, half-broken code every time. I stand firmly that big organic ecosystem of packages and thin library is the right way, and all we need is just better tools to manage trust and quality. https://twitter.com/dpc_pw/status/1166754923381280768 https://twitter.com/dpc_pw/status/1166754923381280768
  - johnisgood 7y ago
    1. If it is really common, then yes. Why not? It does not necessarily stagnate or slow down anything. People working on current official crates can do that were it in the standard library. 2. I am not so sure about that. There are many crates that are just a few lines of code. They are not that difficult to get right, but the mentality dictates that you import a crate instead of writing those "easy" one to ten lines. I am not sure it is the right way of doing it because it suffers from the same problems npm does. Making (and maintaining) more tools to patch up these issues is not exactly a great solution to me. What if these tools have issues, too? Do we create tools to patch up the issues of these other tools, ad infinitum? Few lines of code you write yourself, or: https://pbs.twimg.com/media/EDCMkVMXkAIwdI1.png https://pbs.twimg.com/media/EDCMkVMXkAIwdI1.png
    - steveklabnik 7y ago
      > Why not? It does not necessarily stagnate or slow down anything. People working on current official crates can do that were it in the standard library. It is much, much, much harder to work on the standard library than an external package. If you think Rust compile times are poor, you should try building the compiler (which is needed to work on the standard library.) This alone slows down development a bunch. You also have to deal with the PR queue, RFCs for new functionality, etc. It's more heavy weight for good reason, but it's also heavy weight. It also means that the API must be set in stone forever.
      - pjmlp 7y ago
        No, it means that a process must be put in place to deprecate them, and remove them after a couple of major releases. Even Java has started to actually remove deprecated APIs.
        steveklabnik 7y ago
        Sure, If the rules were different, things would be different. We’re not doing that, nor do we foresee doing that any time soon, if ever.
    - nindalf 7y ago
      The Rust standard library endeavours to do as little as possible and even then, there have been cases where something was added and later folks realised it was a mistake. For example std::sync::mpsc. No one is recommended to use it (crossbeam crate is the preferred alternative). Getopt used to be in the standard library (clap crate is better). Obviously mpsc shouldn't be in the standard library but it can't be removed without breaking backwards compat - essentially stagnating. So a suboptimal solution remains. Rust's solution is to have an official "cookbook" that shows how to use these crates to accomplish common tasks. For example, crossbeam is featured here - https://rust-lang-nursery.github.io/rust-cookbook/concurrency/threads.html https://rust-lang-nursery.github.io/rust-cookbook/concurrenc.... In case a better library comes along, it's simple to update the cookbook. In this scenario's no one's programs are broken and the standard library remains slim. Do you disagree with the cookbook approach?
swsieber 7y ago
As great as that tool is (I do think it's good) I wouldn't call that a solution, I'd call that a mitigation. If the ecosystem is terrible (dependency-bloat wise), then a tool like that doesn't make a big impact.
- burntsushi 7y ago
  I think the biggest problem crev has is adoption. But if it solves that, then I disagree that it doesn't help with the dependency bloat problem. It would serve as pressure against adding dependencies, because with crev, adding dependencies becomes a lot more work because of the code review system. That in and of itself may be enough pressure to reduce the dependency bloat problem. It's a big if---especially adoption---but it makes sense to me.
  - feanaro 7y ago
    Something that requires a lot of work sounds like something people will be hesitant to use.
    - burntsushi 7y ago
      Hence my acknowledgment that adoption is the biggest problem to overcome for crev. :-)
- sriram_sun 7y ago
  I hope this takes off. In this really good talk https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ Hillel mentions that (I'm paraphrasing) one metric that positively affects code quality is code review.

But also has a solution: https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev

by dpc_pw 7y ago

But also has a solution: https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev

floor_ 7y ago

This is a solution to a problem that shouldn't have happened in the first place.

swsieber 7y ago
It's a naturally occurring phenomena when publishing packages is easy. There are various ways to address it: * Make it harder to publish * Make it easier to find quality packages I'd prefer the latter.
- deleted 7y ago
  [deleted]
dpc_pw 7y ago
The alternatives are: * Have every single common thing live in a standard library which makes them stagnate, slows down language development and so on. * Have people roll their own half-baked, half-broken code every time. I stand firmly that big organic ecosystem of packages and thin library is the right way, and all we need is just better tools to manage trust and quality. https://twitter.com/dpc_pw/status/1166754923381280768 https://twitter.com/dpc_pw/status/1166754923381280768
- johnisgood 7y ago
  1. If it is really common, then yes. Why not? It does not necessarily stagnate or slow down anything. People working on current official crates can do that were it in the standard library. 2. I am not so sure about that. There are many crates that are just a few lines of code. They are not that difficult to get right, but the mentality dictates that you import a crate instead of writing those "easy" one to ten lines. I am not sure it is the right way of doing it because it suffers from the same problems npm does. Making (and maintaining) more tools to patch up these issues is not exactly a great solution to me. What if these tools have issues, too? Do we create tools to patch up the issues of these other tools, ad infinitum? Few lines of code you write yourself, or: https://pbs.twimg.com/media/EDCMkVMXkAIwdI1.png https://pbs.twimg.com/media/EDCMkVMXkAIwdI1.png
  - steveklabnik 7y ago
    > Why not? It does not necessarily stagnate or slow down anything. People working on current official crates can do that were it in the standard library. It is much, much, much harder to work on the standard library than an external package. If you think Rust compile times are poor, you should try building the compiler (which is needed to work on the standard library.) This alone slows down development a bunch. You also have to deal with the PR queue, RFCs for new functionality, etc. It's more heavy weight for good reason, but it's also heavy weight. It also means that the API must be set in stone forever.
    - pjmlp 7y ago
      No, it means that a process must be put in place to deprecate them, and remove them after a couple of major releases. Even Java has started to actually remove deprecated APIs.
      - steveklabnik 7y ago
        Sure, If the rules were different, things would be different. We’re not doing that, nor do we foresee doing that any time soon, if ever.
  - nindalf 7y ago
    The Rust standard library endeavours to do as little as possible and even then, there have been cases where something was added and later folks realised it was a mistake. For example std::sync::mpsc. No one is recommended to use it (crossbeam crate is the preferred alternative). Getopt used to be in the standard library (clap crate is better). Obviously mpsc shouldn't be in the standard library but it can't be removed without breaking backwards compat - essentially stagnating. So a suboptimal solution remains. Rust's solution is to have an official "cookbook" that shows how to use these crates to accomplish common tasks. For example, crossbeam is featured here - https://rust-lang-nursery.github.io/rust-cookbook/concurrency/threads.html https://rust-lang-nursery.github.io/rust-cookbook/concurrenc.... In case a better library comes along, it's simple to update the cookbook. In this scenario's no one's programs are broken and the standard library remains slim. Do you disagree with the cookbook approach?

swsieber 7y ago

As great as that tool is (I do think it's good) I wouldn't call that a solution, I'd call that a mitigation. If the ecosystem is terrible (dependency-bloat wise), then a tool like that doesn't make a big impact.

burntsushi 7y ago
I think the biggest problem crev has is adoption. But if it solves that, then I disagree that it doesn't help with the dependency bloat problem. It would serve as pressure against adding dependencies, because with crev, adding dependencies becomes a lot more work because of the code review system. That in and of itself may be enough pressure to reduce the dependency bloat problem. It's a big if---especially adoption---but it makes sense to me.
- feanaro 7y ago
  Something that requires a lot of work sounds like something people will be hesitant to use.
  - burntsushi 7y ago
    Hence my acknowledgment that adoption is the biggest problem to overcome for crev. :-)
sriram_sun 7y ago
I hope this takes off. In this really good talk https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ Hillel mentions that (I'm paraphrasing) one metric that positively affects code quality is code review.