> 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 regu

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