Stdx - The missing batteries of Rust


I love this idea.

I don’t think the time crate is very good. I haven’t used any alternatives, but if there are better libraries available they should be used instead.

I think it would be good to have some math libraries as an optional feature, maybe linalg or cgmath?

Looking at the huge list of libraries distributed with python, I also find that I use the csv/xml libraries a lot. I find being able to generates CSV’s in python very convenient, and I think the somewhat low download count on might be other people (like I do) currently prefer other languages like Python to generates CSV’s because it’s built in. I might switch to Rust for this instead if it was in the stdx crate.


@DanielKeep here’s a PR to simply remove flate2 and hyper since they don’t meet the needed criteria of working everywhere: What do you think?


I’m a fan of chrono in theory, but I’m not sure if people are actually using it. Does anybody know if chrono completely replaces the time crate?


I’m going through now and documenting the remaining crates that are already included.


Can I suggest num_cpus? It’s certainly one I was vaguely surprised to find wasn’t in the stdlib.


Yeah, serializing structs to and from JSON is so simple and common that it almost warrants an explicit mention. Maybe a FAQ of the form “How do I do X?” would be beneficial as well in stdx.

Great feedback, thanks.


num_cpus is probably worthwhile, yeah.


num is something I’d expect to be there as well.


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.