3 ms·

I keep waiting for something like this for Rust. Call it the BatteriesIncluded2022 crate and do an annual release cycle. If it could get a nod from the official

I keep waiting for something like this for Rust. Call it the BatteriesIncluded2022 crate and do an annual release cycle. If it could get a nod from the official Rust maintainers, all the better. Something that is roughly analogous to the Python/Go standard libraries allowing to stand up quite a bit more software without pulling in a hundred different crates.

waaveshine 4y ago
What things would you like to see included that aren’t currently in the standard library?
- 41b696ef1113 4y ago
  Fair question. Noting that I am a Python person who has only tooled around with Rust a bit, a few packages I think warrant inclusion because the base options are too anemic: - Command line parsing (more feature rich the manually iterating over args) - (De)Compression: tar, zip, gzip, bzip2 - CSV parser - Date time - Hashing: md5, sha1, sha256 - HTTP requests - Logging - Random generation: ints, floats, sampling, uuids - Regex - SQLite bindings - (De)serialization: json, ini, toml, yaml - System niceties: where is user home?, # of cpus? Appreciating some of these are quite complex, and probably best left to a crate that has more leeway in experimentation/breaking APIs. Edit: tried to make the formatting less bad
  - waaveshine 4y ago
    Maybe some of these can be chalked up to language philosophy or APIs as you said, but many of these would be welcome additions in my eyes. I think regex, time, and crates like num_cpus would especially be nice to have. There's plenty of those types of crates where it feels like you can't compile a single project without seeing it float by as you build the dependencies.
    - shepmaster 4y ago
      > and crates like num_cpus https://doc.rust-lang.org/std/thread/fn.available_parallelism.html https://doc.rust-lang.org/std/thread/fn.available_parallelis... — Rust 1.59
epage 4y ago
The Rust Cookbook [0] was meant to be one way of maintaining a curated list of crates though I don't know how much attention it has received since the 2018 edition documentation blitz. As for a central batteries-included crate, its been tried a couple of times (e.g. stdx, ergo). Some things that I think would help drive it forward - RFC 3243 [1] to allow for a central "front" for these crates without having to actually compile what you don't need or feature flags - A compelling reason for people to adopt it. For a lot of existing projects, there isn't much motivation. I see the biggest benefit mostly being for prototyping and new users, so they need to cater to these users. Don't just re-export existing crates but lay things out in a natural, discoverable way. Also consider making things easier by keeping the Rust language knowledge to a minimum for end-users (even avoiding lifetimes where possible), don't overwhelm users with choices that won't matter in these contexts, etc. If the user needs more performance or flexibility, they can scale up to the crates being wrapped I'm interested in working in this space but need to wrap up some other projects first. If anyone wants to work on this and is looking for a mentor, feel free to reach out to me. [0] https://rust-lang-nursery.github.io/rust-cookbook/intro.html https://rust-lang-nursery.github.io/rust-cookbook/intro.html [1] https://github.com/rust-lang/rfcs/pull/3243 https://github.com/rust-lang/rfcs/pull/3243
- 41b696ef1113 4y ago
  >A compelling reason for people to adopt it. I could imagine that security conscious products (medical, automotive, network applications) would feel more comfortable if there was a definitive release that could be cited as the basis for the work. Hardly absolves the requirements that would go into a regulated product, but it could be a minor step in the right direction. >Don't just re-export existing crates but lay things out in a natural, discoverable way. Complete agreement there. If there were ever to be a sanctioned "batteries crate" it needs to be more than slapping together a meta directory and calling it a day. I think the Lua Penlight project stands as an example of this.

waaveshine 4y ago

What things would you like to see included that aren’t currently in the standard library?

41b696ef1113 4y ago
Fair question. Noting that I am a Python person who has only tooled around with Rust a bit, a few packages I think warrant inclusion because the base options are too anemic: - Command line parsing (more feature rich the manually iterating over args) - (De)Compression: tar, zip, gzip, bzip2 - CSV parser - Date time - Hashing: md5, sha1, sha256 - HTTP requests - Logging - Random generation: ints, floats, sampling, uuids - Regex - SQLite bindings - (De)serialization: json, ini, toml, yaml - System niceties: where is user home?, # of cpus? Appreciating some of these are quite complex, and probably best left to a crate that has more leeway in experimentation/breaking APIs. Edit: tried to make the formatting less bad
- waaveshine 4y ago
  Maybe some of these can be chalked up to language philosophy or APIs as you said, but many of these would be welcome additions in my eyes. I think regex, time, and crates like num_cpus would especially be nice to have. There's plenty of those types of crates where it feels like you can't compile a single project without seeing it float by as you build the dependencies.
  - shepmaster 4y ago
    > and crates like num_cpus https://doc.rust-lang.org/std/thread/fn.available_parallelism.html https://doc.rust-lang.org/std/thread/fn.available_parallelis... — Rust 1.59

epage 4y ago

The Rust Cookbook [0] was meant to be one way of maintaining a curated list of crates though I don't know how much attention it has received since the 2018 edition documentation blitz. As for a central batteries-included crate, its been tried a couple of times (e.g. stdx, ergo). Some things that I think would help drive it forward - RFC 3243 [1] to allow for a central "front" for these crates without having to actually compile what you don't need or feature flags - A compelling reason for people to adopt it. For a lot of existing projects, there isn't much motivation. I see the biggest benefit mostly being for prototyping and new users, so they need to cater to these users. Don't just re-export existing crates but lay things out in a natural, discoverable way. Also consider making things easier by keeping the Rust language knowledge to a minimum for end-users (even avoiding lifetimes where possible), don't overwhelm users with choices that won't matter in these contexts, etc. If the user needs more performance or flexibility, they can scale up to the crates being wrapped I'm interested in working in this space but need to wrap up some other projects first. If anyone wants to work on this and is looking for a mentor, feel free to reach out to me. [0] https://rust-lang-nursery.github.io/rust-cookbook/intro.html https://rust-lang-nursery.github.io/rust-cookbook/intro.html [1] https://github.com/rust-lang/rfcs/pull/3243 https://github.com/rust-lang/rfcs/pull/3243

41b696ef1113 4y ago
>A compelling reason for people to adopt it. I could imagine that security conscious products (medical, automotive, network applications) would feel more comfortable if there was a definitive release that could be cited as the basis for the work. Hardly absolves the requirements that would go into a regulated product, but it could be a minor step in the right direction. >Don't just re-export existing crates but lay things out in a natural, discoverable way. Complete agreement there. If there were ever to be a sanctioned "batteries crate" it needs to be more than slapping together a meta directory and calling it a day. I think the Lua Penlight project stands as an example of this.