I think it’s kinda silly that
libc is included, which is a disorganized mess of ffi bindings, but not
I think it’s kinda silly that
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 crates.io.
I’d really prefer an update of crates.io 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 crates.io were more helpful for discovery. Telling people which ones are best-of-breed will require human curation though. If crates.io develops these features then maybe the work that goes into stdx can be folded into crates.io.
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.
+1 for one crate per thing. Do one thing, do it best is the right way.
If you look at the Clojure ecosystem, they used to have such a stdx thing called
clojure.contrib. But it was soon broken into several minimal libraries focus on only one purpose, like data.csv, data.json, core.match, core.cache…
It’s really necessary to have the concept
stdx. It’s an organization, and a standard. We need define standard for these libraries to follow, for example, API design, documentation standards, test coverage, coding style and release process. But it doesn’t mean we will have release the whole thing in a monolithic crate.
stdx can be agiler than std, users won’t wait weeks or months for a feature, so each library could have it’s own release cycle and don’t have to wait anything unrelated in other module.
There’s also similar organization in Clojure community called ClojureWerkz.
I’m not going to be able to get a release out for Rust 1.2, but I am still keen on curated libs and want to get back to this in time to release for 1.3.
I’ve brought stdx up to date. I’ve also reconceptualized it as in integration test suite and teaching tool.
As part of our ongoing efforts to improve cross compilation I hope to use this as a way to test that Rust basics work in a wide range of cross-compile scenarios.
I’d like to use skeptic to write a bunch of integration examples in markdown files, which can then be used as tests, but we’ll see I ever get to it.
I’d love to see a coroutine / green threading library as part of this tool kit.
I’ve built an IMAP client https://github.com/GildedHonour/atarashii_imap At the moment it’s under development but already can be used.
You mean like mioco?
The recent discussions around this subject motivated me to refresh stdx.
It’s now up to date with Rust 1.15 and custom derive. The version is 0.115.0-rc, with the
-rc on there because the 0.9 serde line is still only in
This was a big revision, and stdx is now firmly oriented toward teaching, with a single illustrative example of every single crate. I made a bunch of changes to the crate composition, with clap replacing docopt, adding reqwest, rayon, error-chain, and others. There are too many changes to describe, so please give it a look.
This as an interesting upgrade experience. The stdx Cargo.toml file uses exact version requirements, and this time that exposed an incompatibility between the crates I was using, where clap wouldn’t let me upgrade libc fully.
That made me realize that, even if stdx never becomes a crate that one would use like std, simply linking it into your crate dag has an interesting, and fairly desirable effect of locking down these crates to the stdx-approved version. I think there’s a lot of possibilities for verification along those lines, like testing arbitrary crates using the stdx version lock to ensure broad compatibility.
I also noticed that there are a number of crates here with
serde features, and none are yet compatible with the 0.9 series. I think
stdx and projects like it can take a role in ensuring that e.g. all the
stdx crates are working correctly with serde and otherwise establishing conventions for compile-time features.
I agree that many people use the
rand crate, but IMO the design of that crate’s API and its implementation isn’t good, and it is acknowledged to be in need of redesign by several people. I pointed out some of the most egregious and obvious issues in https://github.com/rust-lang/rust/issues/27703#issuecomment-178143920 and the following comments in that thread.
Therefore, I think
rand should be removed.
Also, to what extent is this crate just @brson’s suggestions, and to what extent is it an endorsement from the Rust Language and/or Rust Libraries teams? In particular, should nobody bother trying to make things better than these things because these are the official-but-not-official crates for these things?
stdx is updated to 0.115.0 for Rust 1.15. This brings all crates up to their latest revision.
I’m pretty sure the
stdx crate should be better advertised. I’m newbie and I’ve been digging crates.io for quite a long time now, and I just realised that there’s this crate collection with many-many things I’ve been looking for…