4 ms·

A couple of commong APIs I can think off the top of my head: - HTTP client - CSV parser/generator I know Hyper and rust-csv are popular. But having an stdlib

by pcx 8y ago

A couple of commong APIs I can think off the top of my head: - HTTP client - CSV parser/generator I know Hyper and rust-csv are popular. But having an stdlib that's much more feature complete would be great.

steveklabnik 8y ago
Yeah, I can totally appreciate the perspective, but without a significant set of policy changes, I don't see either of these happening. We'll see!
- oblio 8y ago
  Maybe after the community chooses a few “winners” the Rust devs could promote them as being “suggested” packages? Also, some suggested metapackages/bundles wouldn’t hurt for newbies, like a set of crates for developing command line tools, for example. Something like this: https://marketplace.visualstudio.com/ https://marketplace.visualstudio.com/
  - steveklabnik 8y ago
    It depends, the team suggested this kind of thing two years ago, and the community pretty resoundingly rejected the idea.
    - swsieber 8y ago
      And the community does (organically) pick defacto winners. Like chrono, serde and rust csv (well, I'm not sure about rust csv). It might be nice to have autogenerated docs about the most used soltuions, but I guess the rust cook book sort of fills that niche.
  - staticassertion 8y ago
    Why choose a winner? What if a 'winner' today is a loser in a year? What if we come up with a new approach to solving a problem that requires a breaking change, or a new crate? Would someone be inclined to try to improve the state of HTTP given a good enough version in std? Would we be ok with discouraging that sort of competitive approach? To be honest, all I see are downsides to having a huge std lib. The benefit seems to be that there isn't an obvious, de facto choice for what crates to use. But I think that's a problem better solved by crates.io.
    - dikaiosune 8y ago
      I tend to agree, but I also think that there's a little bit of nuance here. For one thing, I have definitely enjoyed using a large standard library...when I didn't have access to cargo or tools of similar quality. My impression is that many of those who are asking for Rust's stdlib to grow are also/actually asking "please make it really easy for me to use these APIs that I care about," to which I would respond "it's OK, code can be easy to reuse even if it's not in the stdlib," "try cargo," and "crates.io needs to continue improving on discoverability." EDIT: also, hi!
      - staticassertion 8y ago
        Hiiii. I think we're likely on the same page. The desire to make writing an HTTP server that much easier by providing a quick-to-use solution is entirely reasonable. I just don't believe the solution is some 'sanctioned', permanent addition to std. Better to be solved in crates.io.
      - galangalalgol 8y ago
        To make it into some industries it needs to also be easy to grab a snapshot of all the batteries and do mods and licensing checks/approvals before doing a network unconnected install. Running a crates clone may or may not make sense. For some cases grabby an image on a thumb drive or DVD and doing a standalone install on a single machine makes sense.
    - oblio 8y ago
      You misread what I said. Click my link and tell me what you see. Hint: there’s a reason those things are called “suggested extensions”.
    - beefsack 8y ago
      Perhaps a better idea might be to include the most popular client in some form of official tutorial / guide / documentation, or as part of some extended documentation separate to the language doc? That way libraries can coexist, but new developers have a single doc location to go to to find really common usages.
- curun1r 8y ago
  An interesting compromise might be a crate maintained by the core team (std-ext?) that simply re-exports crates under generic names that the community has blessed as being, for better or worse, the default in the Rust ecosystem. So someone who wants batteries included could add only std-ext as a dependency and get hyper as std_ext::http, regex as std_ext::regex, rust-csv as std_ext::csv and such to avoid needing awareness of the entire ecosystem when first starting out. Seasoned Rust developers would probably continue pulling in dependencies directly, but it might improve the experience for new Rust developers to have everything a 'use' statement away without needing to go look for it.
  - steveklabnik 8y ago
    Several of these kinds of initiatives, in various forms, have been tried. They never really caught on. (The biggest was stdx)
all_blue_chucks 8y ago
HTTP client: https://docs.rs/reqwest/0.8.5/reqwest/ https://docs.rs/reqwest/0.8.5/reqwest/
nickm12 8y ago
These are really interesting examples. In Python, the HTTP client in the standard lib is pretty crappy compared to requests, which is the defacto standard. Likewise, the CSV library in the Python stdlib is not very good, but can't improve much for compatibility reasons. Developers have different needs. Some value stability, some value bleeding edge features. Trying to put libraries in the standard library and freezing their interface is really tricky to balance. Though the ecosystem is still young, the long term story for "batteries included" in Rust is going to be a rich ecosystem in Cargo, not a rich standard library.

by pcx 8y ago

steveklabnik 8y ago

Yeah, I can totally appreciate the perspective, but without a significant set of policy changes, I don't see either of these happening. We'll see!

oblio 8y ago
Maybe after the community chooses a few “winners” the Rust devs could promote them as being “suggested” packages? Also, some suggested metapackages/bundles wouldn’t hurt for newbies, like a set of crates for developing command line tools, for example. Something like this: https://marketplace.visualstudio.com/ https://marketplace.visualstudio.com/
- steveklabnik 8y ago
  It depends, the team suggested this kind of thing two years ago, and the community pretty resoundingly rejected the idea.
  - swsieber 8y ago
    And the community does (organically) pick defacto winners. Like chrono, serde and rust csv (well, I'm not sure about rust csv). It might be nice to have autogenerated docs about the most used soltuions, but I guess the rust cook book sort of fills that niche.
- staticassertion 8y ago
  Why choose a winner? What if a 'winner' today is a loser in a year? What if we come up with a new approach to solving a problem that requires a breaking change, or a new crate? Would someone be inclined to try to improve the state of HTTP given a good enough version in std? Would we be ok with discouraging that sort of competitive approach? To be honest, all I see are downsides to having a huge std lib. The benefit seems to be that there isn't an obvious, de facto choice for what crates to use. But I think that's a problem better solved by crates.io.
  - dikaiosune 8y ago
    I tend to agree, but I also think that there's a little bit of nuance here. For one thing, I have definitely enjoyed using a large standard library...when I didn't have access to cargo or tools of similar quality. My impression is that many of those who are asking for Rust's stdlib to grow are also/actually asking "please make it really easy for me to use these APIs that I care about," to which I would respond "it's OK, code can be easy to reuse even if it's not in the stdlib," "try cargo," and "crates.io needs to continue improving on discoverability." EDIT: also, hi!
    - staticassertion 8y ago
      Hiiii. I think we're likely on the same page. The desire to make writing an HTTP server that much easier by providing a quick-to-use solution is entirely reasonable. I just don't believe the solution is some 'sanctioned', permanent addition to std. Better to be solved in crates.io.
    - galangalalgol 8y ago
      To make it into some industries it needs to also be easy to grab a snapshot of all the batteries and do mods and licensing checks/approvals before doing a network unconnected install. Running a crates clone may or may not make sense. For some cases grabby an image on a thumb drive or DVD and doing a standalone install on a single machine makes sense.
  - oblio 8y ago
    You misread what I said. Click my link and tell me what you see. Hint: there’s a reason those things are called “suggested extensions”.
  - beefsack 8y ago
    Perhaps a better idea might be to include the most popular client in some form of official tutorial / guide / documentation, or as part of some extended documentation separate to the language doc? That way libraries can coexist, but new developers have a single doc location to go to to find really common usages.
curun1r 8y ago
An interesting compromise might be a crate maintained by the core team (std-ext?) that simply re-exports crates under generic names that the community has blessed as being, for better or worse, the default in the Rust ecosystem. So someone who wants batteries included could add only std-ext as a dependency and get hyper as std_ext::http, regex as std_ext::regex, rust-csv as std_ext::csv and such to avoid needing awareness of the entire ecosystem when first starting out. Seasoned Rust developers would probably continue pulling in dependencies directly, but it might improve the experience for new Rust developers to have everything a 'use' statement away without needing to go look for it.
- steveklabnik 8y ago
  Several of these kinds of initiatives, in various forms, have been tried. They never really caught on. (The biggest was stdx)

all_blue_chucks 8y ago

HTTP client: https://docs.rs/reqwest/0.8.5/reqwest/ https://docs.rs/reqwest/0.8.5/reqwest/

nickm12 8y ago

These are really interesting examples. In Python, the HTTP client in the standard lib is pretty crappy compared to requests, which is the defacto standard. Likewise, the CSV library in the Python stdlib is not very good, but can't improve much for compatibility reasons. Developers have different needs. Some value stability, some value bleeding edge features. Trying to put libraries in the standard library and freezing their interface is really tricky to balance. Though the ecosystem is still young, the long term story for "batteries included" in Rust is going to be a rich ecosystem in Cargo, not a rich standard library.