I'd argue that if you know what Option.and_then does, you do know what a monad is. and_then, known as flat_map or bind in the generic case, is the quintessential operation of a monad.
One of my biggest gripes with Rust (and other languages) is lack of a good monad abstraction (and accompanying syntactic sugar). But I also acknowledge that this is a "I have done too much category theory" problem and and_then is probably a more reasonable name to those not familiar with this particular area of maths.
> I still don't get what they have to do with i/o in Haskell, but am ok with i/o in Haskell being one of my life's forever unknowable mysteries.
They don't. Not really, anyway. IO happens to be a monad, but that's not really relevant to it being used as an abstraction around side effects. Haskell being a pure language is at odds with the necessity of some side-effects, such as printing to the console. The solution is to construct a "to-do list of actions" or "blueprint" for desired side-effects. This is an instance of IO. Any such blueprint that is assigned to the name "main" is executed. That's it.
The monad part comes in when you want to construct this blueprint. It so happens that one reasonable way to do this is via flat_map.
> One of my biggest gripes with Rust (and other languages) is lack of a good monad abstraction (and accompanying syntactic sugar). But I also acknowledge that this is a "I have done too much category theory" problem and and_then is probably a more reasonable name to those not familiar with this particular area of maths.
I'm happy that Rust has iterators and I don't have to think about what a monad is at all.
One of my biggest gripes with Rust (and other languages) is lack of a good monad abstraction (and accompanying syntactic sugar). But I also acknowledge that this is a "I have done too much category theory" problem and and_then is probably a more reasonable name to those not familiar with this particular area of maths.
> I still don't get what they have to do with i/o in Haskell, but am ok with i/o in Haskell being one of my life's forever unknowable mysteries.
They don't. Not really, anyway. IO happens to be a monad, but that's not really relevant to it being used as an abstraction around side effects. Haskell being a pure language is at odds with the necessity of some side-effects, such as printing to the console. The solution is to construct a "to-do list of actions" or "blueprint" for desired side-effects. This is an instance of IO. Any such blueprint that is assigned to the name "main" is executed. That's it.
The monad part comes in when you want to construct this blueprint. It so happens that one reasonable way to do this is via flat_map.