> Functional programming has gone mainstream about 10-20 years ago when javascript, Go, Rust and a few more recent other things took off.
The problem with this is that Javascript, Go, and Rust are merely "multi-paradigm" (meaning imperative and procedural / object-oriented) languages, not functional programming languages. They may have some of the trappings of functional programming such as first-class closures, but they lack the mathematical functions (i.e. pure functions which deterministically map formal arguments to results with no side effects, as opposed to imperative procedures) which are the key concept of functional programming. You can't achieve functional programming by adding closures or coroutines or procedures-as-values to an imperative language. You can only get there by removing things like side effects which are incompatible with functions.
Of course a program which consists of nothing but mathematical functions isn't very useful, since it can't interact with its runtime environment (no I/O), so you end up with a split between an imperative outer shell (e.g. the Haskell runtime) and a functional program which computes a stream of actions from a corresponding stream of inputs. At that point the concept of monads becomes very helpful to ensure that your input and output (action) streams remain synchronized and that the type of each input matches the corresponding action. As a bonus, the monad concept can be generalized to work in areas other than I/O (exception handling, nondeterministic computation, and probabilistic modeling, to name a few), and you can design combinators (e.g. loops) which are useful in any monadic context, not just the I/O context for which most languages provide special syntax.
The problem with this is that Javascript, Go, and Rust are merely "multi-paradigm" (meaning imperative and procedural / object-oriented) languages, not functional programming languages. They may have some of the trappings of functional programming such as first-class closures, but they lack the mathematical functions (i.e. pure functions which deterministically map formal arguments to results with no side effects, as opposed to imperative procedures) which are the key concept of functional programming. You can't achieve functional programming by adding closures or coroutines or procedures-as-values to an imperative language. You can only get there by removing things like side effects which are incompatible with functions.
Of course a program which consists of nothing but mathematical functions isn't very useful, since it can't interact with its runtime environment (no I/O), so you end up with a split between an imperative outer shell (e.g. the Haskell runtime) and a functional program which computes a stream of actions from a corresponding stream of inputs. At that point the concept of monads becomes very helpful to ensure that your input and output (action) streams remain synchronized and that the type of each input matches the corresponding action. As a bonus, the monad concept can be generalized to work in areas other than I/O (exception handling, nondeterministic computation, and probabilistic modeling, to name a few), and you can design combinators (e.g. loops) which are useful in any monadic context, not just the I/O context for which most languages provide special syntax.