Stdx - The missing batteries of Rust


This is exactly what I was wondering as well. While I think a collection like this is generally a good thing, I think it also introduces a few idiosyncrasy such as the above situation.

Personally, I’d prefer something akin to a “blessed” yet still bastard-love-child of awesome-rust and this project. This way you also avoid things such as the log4rs / env_logger opinions because you can list both and state why one would pick one versus the other in certain situations and still maintain a very curated list (i.e. not listing every single log crate out there). You also don’t have to worry about a project breaking do to a crate swap, or constantly tracking changes to stdx.


Hence the ‘within reason’ part. I am not at all familiar with the 2 alternative logging libraries, so I was just making a general statement.


Here are my thoughts on versioning and stability:

  • The version numbers are less than 1.0 forever, allowing for arbitrary breakage.
  • Releases of stdx correspond to stable of releases of Rust, and point releases therof should not be breaking, i.e. 0.102.1 is a true point release and compatible with 0.102.1.
  • Releases that correspond to different releases of Rust have no stability guarantees, i.e. regex may be upgraded through breaking changes, rustc-serialize may be completely removed.


It seems obvious this should be named libextra.


Can’t we just have an official list of “blessed” packages encouraged to be used by Rust core team? It could come with a list of “wanted” packages that core rust team would like to have produced by community.


Yes, that could probably happen. In some sense those are the packages under rust-lang, but also those could be these. In my opinion it’s probably not the work of the core team though, since they are few and have varying interests.


I think community could nominate package candidates, and core team could use help of trusted community members.


But… that’s what stdx is, more or less. It’s just that it’s actually usable in code, which I regard as an advantage.


Donno. Maybe you’re right (that it’s an advantage).


I think this project is a great idea. Only the essential low-level stuff should go in std, and gathering battle-tested crates is really nice to avoid wasting time on “what crate to use”.


I really like the idea of a curated list of crates, but I see no reason for using stdx or a similiar collection as a dependency. Adding dependencies is so simple with cargo. Packages depending on stdx should not be allowed on since they pull many unneeded dependencies.


I think it’s kinda silly that libc is included, which is a disorganized mess of ffi bindings, but not winapi.


I really don’t think either crate should be exposed by stdx. libc is a very popular create because it is a dependency of many other libraries; both libraries are really second order-libraries (libraries for libraries).


@stebalien I’d argue that std is exactly a “library for a library”, so
putting it in stdx doesn’t seem that crazy. Although it’s perhaps a bit
"rude" for a simple library to depend on stdx, it’s a great way to get
started (and “free” if your consumer depends on it too!).


Half joking: if stdx 0.102 is for Rust 1.2.0, this scheme will overflow in “only” 11 years when Rust 1.100.0 is released. (And as mentioned elsewhere, not releasing Rust 2.0 for a long time would be a sign of success IMO.)


I think it is redundant with
I’d really prefer an update of to mention (with keywords/categories etc …) that these libraries are for generating random numbers and this one in particular is considered the best in most situations.
The workload looks similar but it avoids having an additional layer.


The current list is just what I picked to bootstrap the idea. We can add more!


What an amazing problem to have! When the time comes I will remember to point to your post and say ‘you called it’. Seriously, though we can still change the versioning scheme.


It would be great if were more helpful for discovery. Telling people which ones are best-of-breed will require human curation though. If develops these features then maybe the work that goes into stdx can be folded into


I’ve filled out descriptions of the existing crates. Things I’d like to do next:

  • Add more crates based on the suggestions here
  • Add a usage faq. A guide with simple recipes for common tasks, hopefully that combine the libraries in interesting ways. Doubles as a test suite (*).
  • Get reexported macros working
  • Publish 0.102.0-beta.1

(*) Part of my ambition for stdx is to help with Rust regression testing. stdx provides a set of specific revisions of popular libraries that can be exercised by tools like crater and ctrs, and if we can also provide a test suite that exercises them all together, that is really useful for future compiler writers.