Stdx - The missing batteries of Rust


#22

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 crates.io 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.


#23

@DanielKeep here’s a PR to simply remove flate2 and hyper since they don’t meet the needed criteria of working everywhere: https://github.com/brson/stdx/pull/3. What do you think?


#24

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?


#25

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


#26

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


#27

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.


#28

num_cpus is probably worthwhile, yeah.


#29

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


#30

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.


#31

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.


#32

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.

#33

It seems obvious this should be named libextra.


#34

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.


#35

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.


#36

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


#37

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.


#38

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


#39

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”.


#40

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 crates.io since they pull many unneeded dependencies.


#41

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