Yes, it's a pure library. But this sort of thing is becoming standard for Rust. If your code isn't full of "foo.and_then(|x| ...)" it's uncool. This isn't "functional"; these functions have major side effects.

The bothersome thing is that the control structures of the language are hidden under object-specific functions. "Things really start getting interesting with futures when you combine them. There are endless ways of doing so." I'd rather have "there's only one way to do it", as in Python, rather than "endless ways of doing so". That usually leads to code that's hard to read and debug. As in "how did control get there?". At least in traditional code, you can see control flow easily. Adding an user-definable level of abstraction hides that.

> This isn't "functional"; these functions have major side effects

uh, no, I've rarely seen adaptors like and_then being used with side effects (folks use regular loops if they want that). Rust doesn't have a strict notion of purity, but that doesn't mean that most rust code isn't pure.

There's nothing wrong with having lots of adaptors scattered around the code, either. It's not less readable, it's just different.

> There are endless ways of doing so." I'd rather have "there's only one way to do it", as in Python

Uh, "there are endless ways of combining future adaptors", not "there are endless ways of solving a problem". Each combination of adaptors solves a different problem (mostly).

> That usually leads to code that's hard to read and debug

This is async code. This has always been hard to read and debug. Futures make the control flow more explicit, if anything (especially if you have async and await), because the flow is now in one place, at least. Grokking manual event loop code is much more annoying.

Sure, the async argument doesn't apply to regular iterators and Option. However, these "object specific functions" are not object specific. All futures have the same adaptors. All iterators have the same adaptors. The only special objects with their own set of such methods are Result and Option. These share the names of the methods, and these are used often enough to justify it. There aren't that many of them either, so this really isn't that big a deal. You just need to know what each of this small number of methods does. It only hides control flow if you're not aware of these methods, which is a state of mind that goes away quickly after the first few rust programs.

Besides, because of the closures it's pretty obvious that some tweaking of control flow is happening, so it isn't hidden. You can check the docs for that function to know exactly what the tweaking is.

I also don't know what you mean by "traditional code", this pattern is exceedingly common in languages which aren't C or C++.

Your definition of cruft is rather strange. Yes, Rust code can be kind of complicated and messy-looking, but it makes sense when you think about it. All the parts justify their existence. IMO, cruft is stuff that doesn't make sense or is extraneous; incidental rather than essential complexity, in general.