Stdx – The Missing Batteries of Rust(github.com)
github.com
Stdx – The Missing Batteries of Rust
https://github.com/brson/stdx
3 comments
This is stale, last commit 5 years ago. Lost of listed crates are still go-to ones, but e.g. for logging nowadays I'd reach for `tracing`.
Looks like a more recent alternative might be: https://blessed.rs
While I can't speak to the quality of this list, it is an interesting illustration of the "batteries included" philosophy of some languages versus others. Having a small core was likely helpful to the early breakout of Rust, and with such a speed and memory oriented language likely continues to be a good choice for system code projects.
In contrast, out of this list, here is what comes out of the box for raku (which sets the gold standard for "kitchen sink" inclusion of everything imaginable):
I think that Larry Wall (the author of perl and then raku) saw the effect of balkanisation of the code base across inconsistent library choices with perl and was keen that raku (formerly known as perl6) would plan for the long term and take the "batteries included" path. Since scripting languages also serve to quickly whip up code, it's handy to have all the tools at your fingertips rather than having to load up modules.
In contrast, out of this list, here is what comes out of the box for raku (which sets the gold standard for "kitchen sink" inclusion of everything imaginable):
- byte order conversion
- date and time
- command line argument parsing
- error handling
- iterator functions
- C interop
- multidimensional arrays
- big, rational, complex numbers
- random numbers
- parallel iteration
- regular expressions
- software versioning
- thread pool
I think that Larry Wall (the author of perl and then raku) saw the effect of balkanisation of the code base across inconsistent library choices with perl and was keen that raku (formerly known as perl6) would plan for the long term and take the "batteries included" path. Since scripting languages also serve to quickly whip up code, it's handy to have all the tools at your fingertips rather than having to load up modules.
Notice that none of these _need_ to be included in the standard library. All of them have benefited from frequent iteration outside of the standard library, and they all have alternatives if you don't like any of the choices that their authors made. But they are all reasonably good default choices if you just need to pick something and get started.
That's true but it's important to not underestimate that importance of defaults. Not only because it's more accessible out of the box, the ecosystem then can rely on it which means that crates you encounter are more likely to integrate nicely with whatever you're doing. Integration with the stdlib can then also be richer vs as a standalone crate. A great example of this is temporary file management. It's silly that's not bundled in the standard library.
That being said, I'm responding to the general philosophy. I haven't looked at anything in this specific crate.
That being said, I'm responding to the general philosophy. I haven't looked at anything in this specific crate.