You can consider monads as being a design pattern that's been shown to be useful when dealing with laziness.
In Haskell they are endemic as the language itself is lazy. However, they are also useful in eager languages where one wishes to model a behaviour in a lazy manner.
The most common examples of the latter are probably: modelling temporal delays in async code (with Futures); delaying processing of exceptions (with Results) and delaying handling of nulls (with Optionals).
Where monads come in handy is that their composability allows you to decide precisely when you want to handle the relevant behaviour.
As with all design patterns they're no silver bullet. They have trade offs as do their alternatives, be that callbacks, exceptions etc. But they can be useful.
You can consider monads as being a design pattern that's been shown to be useful when dealing with laziness.
In Haskell they are endemic as the language itself is lazy. However, they are also useful in eager languages where one wishes to model a behaviour in a lazy manner.
The most common examples of the latter are probably: modelling temporal delays in async code (with Futures); delaying processing of exceptions (with Results) and delaying handling of nulls (with Optionals).
Where monads come in handy is that their composability allows you to decide precisely when you want to handle the relevant behaviour.
As with all design patterns they're no silver bullet. They have trade offs as do their alternatives, be that callbacks, exceptions etc. But they can be useful.