The loom crate is a model checker for concurrent programs. In principle, it allows more in-depth checking by exploring exhaustive combinations of program traces (as opposed to interpreters like Miri). It would in particular be helpful to build confidence in changes like #14.

However, in practice it suffers from several shortcommings:

• As seen in the loom branch, several APIs of the standard library aren't mirrored in loom (yet?), e.g. Missing Condvar::wait_while API tokio-rs/loom#393, Mirror PoisonError from the standard library? tokio-rs/loom#394, Missing impl FromIterator<T> for Arc[T] tokio-rs/loom#395, Missing thread::scope() API tokio-rs/loom#396. This is inconvenient (some code has to be duplicated), although not blocking.
• Testing with RUSTFLAGS="-D warnings --cfg loom" cargo +nightly test --release -- loooom shows that the model is indeed really slow to run for all but the most trivial examples. In particular using relaxed orderings (a304245) causes a combinatorial explosion and only the 2-thread example completed on my machine within 1 minute. This makes the usefulness of Loom quite limited for Paralight at the moment.