3 ms·

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?