Update: One of the optimizations can now be observed, further exploration is indicated.
tl;dr: Two optimizations that would allow writing easy code and let the compiler optimize things out are not performed, so back go manual state machines…
It looks way more complicated than it is.
Maybe I should have rather linked to the “please participate” slide of when I presented this at Rust meetups: https://christian.amsuess.com/presentations/2020/crev/#/step-14
Not directly (at least without admin intervention or transfer of the crate to someone like rust-bus).
What I’d encourage you to do is to create a cargo crev review of the crate, marking it as unmaintained. crates.io won’t show reviews (yet, I hope), but lib.rs has a tab that shows all known reviews (eg. on https://lib.rs/crates/typenum), and statements like “people note in their reviews that this is unmaintained” should show up there.
Looking forward to using .then(), this brings back nice memories of smalltalk.
At least for my use cases it’s already there; especially the ecosystem around embedded-hal is already way ahead of what’s there in C.
The lack of maturity in terms of still developing modules is partially made up for by cargo’s ability to manage different crate versions in dependencies – if some internal part needs v1 of a crate that is now developed in a v3, it can still work (as long as you have a good grasp on its security implications).