5 ms·

I want a step further than upgrading libraries to 1.0. I really want the Rust foundation to package up the essential libraries (bikeshedding to ensue, but somet

I want a step further than upgrading libraries to 1.0. I really want the Rust foundation to package up the essential libraries (bikeshedding to ensue, but something akin to Python or Go), and release those as a single, annual distribution. Even better if they could standardize the API across all of the packages, ensure minimal unsafe, etc. The `rust_stdlib_v2023` could only depend upon itself, and would be a basis for which other projects could then build from there. It annoys me to no end the huge number of packages I pull in for doing something "simple". It is great that packages can be so small and focused, but now I have a real trust problem. How am I possibly supposed to ensure there are no malicious actors in my dependency tree?

Animats 4y ago
There's already a standard library. After that, there's just whatever anybody decided to upload to "crates.io". Nothing in between. Some form of curation and quality control is needed, at least for crates depended upon by other widely used published crates. The Rust foundation's crate manager job is apparently vacant until at least April, so nobody is officially in charge of this. Relevant XKCD: [1] My take on this for game development: [2] [1] https://imgs.xkcd.com/comics/dependency_2x.png https://imgs.xkcd.com/comics/dependency_2x.png [2] https://www.reddit.com/r/rust_gamedev/comments/11b0brr/were_not_really_game_yet/ https://www.reddit.com/r/rust_gamedev/comments/11b0brr/were_...
- fbdab103 4y ago
  Well that is exactly what I think should change. I do not want to have to pull in a package for regex, parsing json, generating a random number, counting the number of available cpus, etc. Quite a lot of standard functionality required across a broad swath of projects. I understand Rust does not want to bring them into core, but I think there should be a middle ground that offers richer functionality to the language without the wild-wild-west of crates.io.
  - UncleEntity 4y ago
    Could be like boost libs. They make the claim that it’s about pushing them into the standard library but some of those libs have been in there forever.
    - fbdab103 4y ago
      I think that's a great comparison. Establish a better baseline standard, but one can always reach out to a cutting edge crate if the library set is insufficient.
      - Animats 4y ago
        It's a useful comparison, although Boost has traditionally been the home of cool template code you're not supposed to understand but can use. For Rust, the problem is widely used crates such as "hyper" (http), "tokio" (support for async), and "glam" (2D and 3D vectors and matrices.) These are widely used, but not part of the standard library. They're not basic enough to be standard, and they all have alternatives. But if you use them, you need them to be stable.
schemescape 4y ago
As someone considering ramping up on Rust, this sounds disturbingly similar to the JavaScript+NPM ecosystem that is frequently criticized here. How far along the ridiculous dependency spectrum towards NPM is crates.io? For example, if I release a piece of nontrivial software built with Rust, how many copyright notices am I going to have to include? (To say nothing of vetting the set of transitive dependencies!)

Animats 4y ago

There's already a standard library. After that, there's just whatever anybody decided to upload to "crates.io". Nothing in between. Some form of curation and quality control is needed, at least for crates depended upon by other widely used published crates. The Rust foundation's crate manager job is apparently vacant until at least April, so nobody is officially in charge of this. Relevant XKCD: [1] My take on this for game development: [2] [1] https://imgs.xkcd.com/comics/dependency_2x.png https://imgs.xkcd.com/comics/dependency_2x.png [2] https://www.reddit.com/r/rust_gamedev/comments/11b0brr/were_not_really_game_yet/ https://www.reddit.com/r/rust_gamedev/comments/11b0brr/were_...

fbdab103 4y ago
Well that is exactly what I think should change. I do not want to have to pull in a package for regex, parsing json, generating a random number, counting the number of available cpus, etc. Quite a lot of standard functionality required across a broad swath of projects. I understand Rust does not want to bring them into core, but I think there should be a middle ground that offers richer functionality to the language without the wild-wild-west of crates.io.
- UncleEntity 4y ago
  Could be like boost libs. They make the claim that it’s about pushing them into the standard library but some of those libs have been in there forever.
  - fbdab103 4y ago
    I think that's a great comparison. Establish a better baseline standard, but one can always reach out to a cutting edge crate if the library set is insufficient.
    - Animats 4y ago
      It's a useful comparison, although Boost has traditionally been the home of cool template code you're not supposed to understand but can use. For Rust, the problem is widely used crates such as "hyper" (http), "tokio" (support for async), and "glam" (2D and 3D vectors and matrices.) These are widely used, but not part of the standard library. They're not basic enough to be standard, and they all have alternatives. But if you use them, you need them to be stable.

schemescape 4y ago

As someone considering ramping up on Rust, this sounds disturbingly similar to the JavaScript+NPM ecosystem that is frequently criticized here. How far along the ridiculous dependency spectrum towards NPM is crates.io? For example, if I release a piece of nontrivial software built with Rust, how many copyright notices am I going to have to include? (To say nothing of vetting the set of transitive dependencies!)